Discussiion: is that compressing ram before hibernating faster?

[Lachu]

I read that compressing ram instead of copy to swap partition is faster. My question is that compresing ram before save to swap and hibernate is faster or slower?

[wolfi323]

I read that compressing ram instead of copy to swap partition is faster. My question is that compresing ram before save to swap and hibernate is faster or slower?

RAM actually _is_ being compressed before it is copied to the swap during hibernation (by default at least).
I think the main reason to do this is to prevent to run out of space, not because it might be faster. After all, the swap has to contain swap+RAM then.

Whether it is faster or not largely depends on your hardware I suppose, and on other factors like how much RAM was actually in use.
I don't think there's a definite answer.

[Lachu]

I know that boot ramdisk and linux kernel is compressed, because decompressing is faster than reading whole kernel from disk.

So maybe compressed ram in swap gives faster re-hibernation,

[wolfi323]

I know that boot ramdisk and linux kernel is compressed, because decompressing is faster than reading whole kernel from disk.

Hm, I think it is compressed mainly so that it doesn't need that much disk space. Especially /boot might be limited if it is a separate partition.

It shouldn't make much difference if you read a 5.5 MiB compressed file or a 25MiB uncompressed file speed-wise.

But of course if reading is slooow, it does make a difference. As I said, it depends on the hardware.
In the case of the kernel and initrd, no drivers are loaded yet, and standard BIOS functions are used for reading, which really might be a lot slower.

So maybe compressed ram in swap gives faster re-hibernation,

Maybe, depending on your hardware.

If you have a slow CPU and a fast hard disk, compressing/decompressing would definitely slow down everything I'd say. (although decompressing is much faster than compressing normally)
OTOH, with a slow hard disk and a fast CPU, compressing probably speeds things up.

In the end, you'd have to measure the difference on _your_ system to see what is faster, I think.

[robin_listas]

On 2015-02-06 15:26, wolfi323 wrote:
> Lachu;2693611 Wrote:

>> I know that boot ramdisk and linux kernel is compressed, because
>> decompressing is faster than reading whole kernel from disk.

> Hm, I think it is compressed mainly so that it doesn't need that much
> disk space. Especially /boot might be limited if it is a separate
> partition.

That is correct.

The boot files were initially compressed so that you could place them in
a small device, such as as floppy disk. Floppies? Who uses them now?
Well... A bootable CD has a section that emulates a floppy. The BIOS
thinks it is booting a floppy, not a CD (look for eltorito estandard).

Then for many years a separate boot partition was required, typically
very small because it was often created by shifting already existing
partitions on disk. We reduced the size of the first partition by a tiny
amount in order to create the linux boot partition at the beginning of
the disk.

So having a small kernel and initrd was very important.


> It shouldn't make much difference if you read a 5.5 MiB compressed file
> or a 25MiB uncompressed file speed-wise.

It did... on some machines. Reading from disk is an electromechanical
operation. Say that we have a 100 MB/s read speed: 25 MB reads in 0.25S,
and 5 MB reads in 0.05S, if I got the numbers right. IF the CPU can
uncompress that chunk in less than 0.25S (probably using one core only),
you gain speed.

However, a 5 times compression ratio is CPU intensive, so chances are
the numbers will not meet.

(why did I say one core only? Well, during the initial boot phase only
one core is enabled. I don't know if this phase (loading the
kernel/loading hibernated image) is before or after this phase).


> But of course if reading is slooow, it does make a difference. As I
> said, it depends on the hardware.

Yep.

> In the case of the kernel and initrd, no drivers are loaded yet, and
> standard BIOS functions are used for reading, which really might be a
> lot slower.

Yep.

I don't know if this is still the case, but the traditional bios run in
8086 mode (not the proper name, but I forgot it). No access to the full
ram and functionality.


>> So maybe compressed ram in swap gives faster re-hibernation,

> Maybe, depending on your hardware.

Yep.

> In the end, you'd have to measure the difference on _your_ system to see
> what is faster, I think.

Yep.

:-)

--
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

[Lachu]

I don't know if this is still the case, but the traditional bios run in
8086 mode (not the proper name, but I forgot it). No access to the full
ram and functionality.

8086 is a correct name. It was first microprocessor of x86 familly.

[hendersj]

On Sat, 07 Feb 2015 07:26:01 +0000, Lachu wrote:

> robin_listas;2693688 Wrote:
>>
>> I don't know if this is still the case, but the traditional bios run in
>> 8086 mode (not the proper name, but I forgot it). No access to the full
>> ram and functionality.
>>
>>
> 8086 is a correct name. It was first microprocessor of x86 familly.

Well, not really; the 8088 was the first CPU used in the IBM PC, and used
the same ALU, registers, and instruction set.

The 8085 also has a lot of similarities as well, and is even still used
today in a lot of fairly mission-critical scenarios (such as aircraft
avionics, IIRC). The SDK-86 was used in my microprocessors class in
college, even though the 8085 was the predominant processor used at the
time for avionics.

Jim

--
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

[wolfi323]

On Sat, 07 Feb 2015 07:26:01 +0000, Lachu wrote:

> robin_listas;2693688 Wrote:
>>
>> I don't know if this is still the case, but the traditional bios run in
>> 8086 mode (not the proper name, but I forgot it). No access to the full
>> ram and functionality.
>>
>>
> 8086 is a correct name. It was first microprocessor of x86 familly.

Well, not really; the 8088 was the first CPU used in the IBM PC, and used
the same ALU, registers, and instruction set.

And proper name for the "8086 mode" is "real mode":
https://en.wikipedia.org/wiki/Real_mode

Before the release of the 80286, which introduced Protected mode, real mode was the only available mode for x86 CPUs.^[1] In the interests of backwards compatibility, all x86 CPUs start in real mode when reset.

[robin_listas]

On 2015-02-09 16:56, wolfi323 wrote:
>


> And proper name for the "8086 mode" is "real mode":
> https://en.wikipedia.org/wiki/Real_mode

Yes, that was what I meant, but failed to remeber.


>> In the
>> interests of 'backwards compatibility'
>> (https://en.wikipedia.org/wiki/Backwards_compatibility), all x86 CPUs
>> start in real mode when reset.

Exactly, that's what I was referring to. Depending when the switch is
made, the CPU runs slower, less efficiently, till it is done, sometime
during kernel booting. Grub probably runs in real mode.

--
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

[Fraser_Bell]

On Sat, 07 Feb 2015 07:26:01 +0000, Lachu wrote:

> robin_listas;2693688 Wrote:
>>
>> I don't know if this is still the case, but the traditional bios run in
>> 8086 mode (not the proper name, but I forgot it). No access to the full
>> ram and functionality.
>>
>>
> 8086 is a correct name. It was first microprocessor of x86 familly.

Well, not really; the 8088 was the first CPU used in the IBM PC, and used
the same ALU, registers, and instruction set.

Sorry to disagree with you, old friend, but:

x86 is a family of backward compatible instruction set architectures[a] based on the Intel 8086 CPU. The 8086 was introduced in 1978 as a fully 16-bit extension of Intel's 8-bit based 8080 microprocessor, with memory segmentation as a solution for addressing more memory than can be covered by a plain 16-bit address. The term "x86" came to being because the names of several successors to the Intel's 8086 processor ended in "86", including 80186, 80286, 80386 and 80486 processors.