Raid 0 Swap?

Marc Perkel · External Since: May 16, 2006 Posts: 46

If I have two drives and I want swap to be fast if I allocate swap spam
on both drives does it break up the load between them? Or would it run
faster if I did a Raid 0 swap?

--
VGER BF report: H 0.286654
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Bernd Eckenfels · External Since: Feb 21, 2005 Posts: 38

In article <44FB5AAD.7020307.DeleteThis@perkel.com> you wrote:
> If I have two drives and I want swap to be fast if I allocate swap spam
> on both drives does it break up the load between them? Or would it run
> faster if I did a Raid 0 swap?

if you set up two swap partitions with the same prio, it will distribute the
access, you dont need striping for that. (However with striping you can a
bit better control the stripe size).

Of course you should not plan for swapping, it is just slow...

Gruss
Bernd

--
VGER BF report: H 0.224635
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Tokarev · External Since: Nov 12, 2004 Posts: 140

Marc Perkel wrote:
> If I have two drives and I want swap to be fast if I allocate swap spam
> on both drives does it break up the load between them? Or would it run
> faster if I did a Raid 0 swap?

Don't do that - swap on raid0. Don't do that. Unless you don't care
about your data, ofcourse. Seriously.

If something with swap space goes wrong, God only knows what will break.
It is trivial to break userspace data this way, when an app is swapped
out and there's an error reading it from swap, its data file very likely
to be corrupt, especially when it is interrupted during file update.
It is probably possible to corrupt the whole filesystem this way too,
when some kernel memory has been swapped out and is needed to write some
parts of filesystem, but it can't be read back.

Ie, your swap space must be reliable. At least not worse than your memory.
And with striping, you've much more chances of disk failure...

Yes it sounds very promising at first, to let kernel stripe swap space,
for faster operations. But hell, first, try to avoid swappnig in the
first place, by installing appropriate amount memory which is cheap
nowadays, so there will be just no need for swapping. And when it's
done, it's not relevant anymore whenever your swap space is fast or
not. But make it *reliable*.

/mjt

--
VGER BF report: U 0.49924
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Helge Hafting · External Since: Mar 29, 2005 Posts: 87

Michael Tokarev wrote:
> Marc Perkel wrote:
>
>> If I have two drives and I want swap to be fast if I allocate swap spam
>> on both drives does it break up the load between them? Or would it run
>> faster if I did a Raid 0 swap?
>>
>
> Don't do that - swap on raid0. Don't do that. Unless you don't care
> about your data, ofcourse. Seriously.
>
> If something with swap space goes wrong, God only knows what will break.
> It is trivial to break userspace data this way, when an app is swapped
> out and there's an error reading it from swap, its data file very likely
> to be corrupt, especially when it is interrupted during file update.
> It is probably possible to corrupt the whole filesystem this way too,
> when some kernel memory has been swapped out and is needed to write some
> parts of filesystem, but it can't be read back.
>
I thought kernel data weren't swapped at all?
Mostly because kernel data could be needed immediately, with
no option of waiting for swapin.
So, bad swap should only really kill userspace programs,
although it probably can cause some bad delays in cases
where the userspace program calls into the kernel,
passing an address that happens to be in damaged swap.
You might then stall the kernel holding some resources
while the disks retries umpteen times.
> Ie, your swap space must be reliable. At least not worse than your memory.
> And with striping, you've much more chances of disk failure...
>
> Yes it sounds very promising at first, to let kernel stripe swap space,
> for faster operations. But hell, first, try to avoid swappnig in the
> first place, by installing appropriate amount memory which is cheap
> nowadays, so there will be just no need for swapping. And when it's
> done, it's not relevant anymore whenever your swap space is fast or
> not. But make it *reliable*.
>
Some swap is nice to have. "Ouch - sluggish server today,
I will have to look into it" is so much better
than "Eww - the OOM serial killer took out another 5 processes,
people are screaming!"

As for reliable swap - swap on raid-1 is nice - and it
probably perform better than single-disk swap too,
although not as fast as striped swap.

Helge Hafting

--
VGER BF report: U 0.498988
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Tokarev · External Since: Nov 12, 2004 Posts: 140

Helge Hafting wrote:
> Michael Tokarev wrote:
[]
>> If something with swap space goes wrong, God only knows what will break.
>> It is trivial to break userspace data this way, when an app is swapped
>> out and there's an error reading it from swap, its data file very likely
>> to be corrupt, especially when it is interrupted during file update.
>> It is probably possible to corrupt the whole filesystem this way too,
>> when some kernel memory has been swapped out and is needed to write some
>> parts of filesystem, but it can't be read back.
>>
> I thought kernel data weren't swapped at all?
> Mostly because kernel data could be needed immediately, with
> no option of waiting for swapin. So, bad swap should only really kill
> userspace programs,
> although it probably can cause some bad delays in cases
> where the userspace program calls into the kernel,
> passing an address that happens to be in damaged swap.
> You might then stall the kernel holding some resources
> while the disks retries umpteen times.

Well, it's not that simple. Kernel uses both swappable and
non-swappable memory internally. For some things, it's
unswappable, for some, it's swappable. In general, it's
impossible to say which parts of kernel will break (and
in wich ways) if swap goes havoc.

>> Ie, your swap space must be reliable. At least not worse than your
>> memory.
>> And with striping, you've much more chances of disk failure...
>> Yes it sounds very promising at first, to let kernel stripe swap space,
>> for faster operations. But hell, first, try to avoid swappnig in the
>> first place, by installing appropriate amount memory which is cheap
>> nowadays, so there will be just no need for swapping. And when it's
>> done, it's not relevant anymore whenever your swap space is fast or
>> not. But make it *reliable*.
>>
> Some swap is nice to have. "Ouch - sluggish server today,
> I will have to look into it" is so much better
> than "Eww - the OOM serial killer took out another 5 processes,
> people are screaming!"

I didn't say "eliminate swap space", I said about trying to avoid
swap usage. In the other words, DO set up swap space, and DO it
in a reliable way. Not "swap isn't needed" - well yes, it's
not entirely clear from my statement.

> As for reliable swap - swap on raid-1 is nice - and it
> probably perform better than single-disk swap too,
> although not as fast as striped swap.

Yes it's slower. But you don't really care, because in normal
life, there should be almost no swap usage. When swapping starts
occuring in amounts where speed difference is noticeable, it's
time to add more memory (or to run less hungry processes),
not to speed up swap space.

/mjt

--
VGER BF report: H 0.182426
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jan Engelhardt · External Since: Jun 24, 2004 Posts: 1116

>> I thought kernel data weren't swapped at all?

If the swap code was swapped, who would swap it in again?

>Well, it's not that simple. Kernel uses both swappable and
>non-swappable memory internally. For some things, it's
>unswappable, for some, it's swappable. In general, it's
>impossible to say which parts of kernel will break (and
>in wich ways) if swap goes havoc.

In general, everything you type in as C code (.bss, .data, .text) should be
unswappable. kmalloc()ed areas are resident too, and kmalloc has a
parameter which defines whether the allocation can/cannot push userspace
pages into the swap (GFP_ATOMIC/GFP_IO). So if there is some
kernel-allocation swapped out, it is most likely to be marked as
'userspace' so that the same algorithms can be used for swapin and -out.

Jan Engelhardt
--

--
VGER BF report: H 5.48632e-07
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Denis Vlasenko · External Since: Jul 28, 2006 Posts: 65

On Monday 04 September 2006 12:46, Jan Engelhardt wrote:
> >> I thought kernel data weren't swapped at all?
>
> If the swap code was swapped, who would swap it in again?
>
> >Well, it's not that simple. Kernel uses both swappable and
> >non-swappable memory internally. For some things, it's
> >unswappable, for some, it's swappable. In general, it's
> >impossible to say which parts of kernel will break (and
> >in wich ways) if swap goes havoc.
>
> In general, everything you type in as C code (.bss, .data, .text) should be
> unswappable. kmalloc()ed areas are resident too, and kmalloc has a
> parameter which defines whether the allocation can/cannot push userspace
> pages into the swap (GFP_ATOMIC/GFP_IO). So if there is some
> kernel-allocation swapped out, it is most likely to be marked as
> 'userspace' so that the same algorithms can be used for swapin and -out.

What are you guys talking about? IIRC kernel doesn't use
swap for its vital data structures. I recall only one
kernel thing which goes into swap: tmpfs data. Caching network
filesystems may also use swappable data, but currently grep
catches only cifs.

IOW swap is for dirtied userspace data. Please correct me
if I am wrong here.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jan Engelhardt · External Since: Jun 24, 2004 Posts: 1116

On Dec 28 2006 00:06, Mike Huber wrote:
>
> I would like to point out one key argument against raid0 swap partitions,
> which is that, should a drive failure occur, the least used programs in
> memory are most drastically affected. Unfortunately, in the case of a
> drastic drive failure in a standalone server, one of the most likely
> programs to be affected is getty, disallowing you from manually logging in.

However, the footprint of getty is rather small, so its chance to run is higher
than an idle bigger task (dbus, resmgr, hal, perhaps cron or X)

-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Bill Davidsen · External Since: Jan 07, 2005 Posts: 313

Jan Engelhardt wrote:
> On Dec 28 2006 00:06, Mike Huber wrote:
>> I would like to point out one key argument against raid0 swap partitions,
>> which is that, should a drive failure occur, the least used programs in
>> memory are most drastically affected. Unfortunately, in the case of a
>> drastic drive failure in a standalone server, one of the most likely
>> programs to be affected is getty, disallowing you from manually logging in.
>
> However, the footprint of getty is rather small, so its chance to run is higher
> than an idle bigger task (dbus, resmgr, hal, perhaps cron or X)

RAID-0 swap is not the thing to run if reliability is a must, clearly.
Interestingly, after a long fight with poor RAID-5 write speed, I moved
my swap to RAID-10, only to find that recovery disks don't know how to
use it. Tried Fedora and then a live CD (puppy, I think).

Detail on the RAID-5 performance thing in the linux-raid archives, won't
rehash here.
--
bill davidsen <davidsen.DeleteThis@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/