[Gllug] performance difference between a swap partition vs a swap file.>>>>>

Nix nix at esperi.org.uk
Thu Dec 3 23:43:25 UTC 2009

On 2 Dec 2009, John Hearns outgrape:

> 2009/12/2 Richard Jones <rich at annexia.org>:
>> > What you'd really want in this case is some way to lock the relevant
>> parts you need into physical RAM.  The kernel is already "locked" in
> As someone with a clue once explained to me (old-time SGI employee and
> trainer on the Altix Evaluation and Performance Tuning course)
> the problem is that the Linux cache has no floor - agreeing with what
> you are saying. In Irix it was possible to set a floor to the cache,

What, a minimum size? In practice there is such a floor on Linux
systems, too: if you have no page cache, you have nothing mmap()ed in
physical memory, thus you have no binaries running, so where's the code
that's provoking the swapping?

I don't really see what advantage this provides.

Linux certainly does try very very *very* hard to retain some free
memory at all times, because if there's none of that left, atomic
allocations from interrupt context are likely to start failing, and
then you have a dead system.

>                             In the Linux world, when a system has run
> out of memory it is common to say "I can't get a login prompt because
> the system is too busy reading/writing to disk", in fact what has
> happened is that the executables you need have been swapped out - and
> you haven't a snowball's chance of getting them back.

Actually when this has happened to me I was generally waiting for
syslog, and syslog is stalled because it can't get any time to write any
of its logs to disk, and then its socket backlog filled up, and then
everything that had to log stalled. Logging in provokes syslog output,

(If the system really was swapping so hard that even a shell couldn't
run at all, then how would you fix it even if you did have a getty
locked into memory? Presumably you need to load a shell and kill(1) as
Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list