Date: Mon, 4 Sep 2006 12:46:31 +0200 (MEST)
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
To: Michael Tokarev <mjt@tls.msk.ru>
cc: Helge Hafting <helge.hafting@aitel.hist.no>, Marc Perkel <marc@perkel.com>,
       linux-kernel@vger.kernel.org
Subject: Re: Raid 0 Swap?
In-Reply-To: <44FBFFFC.90309@tls.msk.ru>
Message-ID: <Pine.LNX.4.61.0609041242350.17115@yvahk01.tjqt.qr>
References: <44FB5AAD.7020307@perkel.com> <44FBD08A.1080600@tls.msk.ru>
 <44FBF62A.1010900@aitel.hist.no> <44FBFFFC.90309@tls.msk.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1099
Lines: 29


>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/