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.
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,
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.
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))
8086 is a correct name. It was first microprocessor of x86 familly.
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
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]](https://en.wikipedia.org/wiki/Real_mode#cite_note-1) In the interests of backwards compatibility, all x86 CPUs start in real mode when reset.
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))
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.
On Thu, 12 Feb 2015 03:06:02 +0000, Fraser Bell wrote:
> hendersj;2693982 Wrote:
>> 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.
Well, yes, but the 8088 was the first IBM PC CPU - I remember working on
a few of those systems myself.
The 8088 and 8086 were instruction-set compatible, the primary difference
(but not the only one) was that the data bus was 8-bit instead of 16-bit,
as I recall.
It was somewhat ironic that the more-capable CPU (the 8086) had a smaller
model number than the less-capable CPU (the 8088).
There also was the V20, a clone of the 8088. One of my first computers
had the V20 in it rather than an 8088.
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C