Re: [RFC][PATCH 2/9] deadlock prevention core

On Sun, 2006-08-13 at 22:22 -0700, Andrew Morton wrote:
On Mon, 14 Aug 2006 07:03:55 +0200
Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:

On Sun, 2006-08-13 at 21:58 -0700, Andrew Morton wrote:
On Mon, 14 Aug 2006 06:40:53 +0200
Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:

Testcase:

Mount an NBD device as sole swap device and mmap > physical RAM, then
loop through touching pages only once.

Fix: don't try to swap over the network. Yes, there may be some scenarios
where people have no local storage, but it's reasonable to expect anyone
who is using Linux as an "enterprise storage platform" to stick a local
disk on the thing for swap.

I wish you were right, however there seems to be a large demand to go
diskless and swap over iSCSI because disks seem to be the nr. 1 failing
piece of hardware in systems these days.

We could track dirty anonymous memory and throttle.

Also, there must be some value of /proc/sys/vm/min_free_kbytes at which a
machine is no longer deadlockable with any of these tricks. Do we know
what level that is?

Not sure, the theoretical max amount of memory one can 'lose' in socket
wait queues is well over the amount of physical memory we have in
machines today (even for SGI); this combined with the fact that we limit
the memory in some way to avoid DoS attacks, could make for all memory
to be stuck in wait queues. Of course this becomes rather more unlikely
for ever larger amounts of memory. But unlikely is never a guarantee.


That leaves MAP_SHARED, but mm-tracking-shared-dirty-pages.patch will fix
that, will it not?

Will makes it less likely. One can still have memory pressure, the
remaining bits of memory can still get stuck in socket queues for
blocked processes.

But there's lots of reclaimable pagecache around and kswapd will free it
up?

Yes, however it is possible for kswapd and direct reclaim to block on
get_request_wait() for the nbd/iscsi request queue by sheer misfortune.
In that case there will be no more reclaim; of course the more active
processes we have the unlikelier this will be. Still with the sheer
amount of cpu time invested in Linux its not a gamble we're likely to
never lose.

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

Relevant Pages

  • Re: Swap space
    ... > twice the amount of RAM if you need to capture a dump for debugging. ... > If you won't ever be doing that, you may not need so much swap. ... least the size of physical memory. ...
    (freebsd-questions)
  • Re: [RFC][PATCH 2/9] deadlock prevention core
    ... Peter Zijlstra wrote: ... don't try to swap over the network. ... We could track dirty anonymous memory and throttle. ... to be stuck in wait queues. ...
    (Linux-Kernel)
  • Re: Heaps and Foreigners
    ... >> can ask for the memory and get a pointer to it. ... cause unfathomable deaths when swap space gets low or is exhausted. ... It's probably because there is some reserve memory to print out errors ... of RAM and disk space) and virtual swap (which is just a number managed ...
    (comp.lang.lisp)
  • Re: Is Greenspun enough?
    ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
    (comp.lang.lisp)
  • Re: [PATCH] io-controller: Add io group reference handling for request
    ... Find the io group bio belongs to. ... anonymous pages (swap) you still need the page tracking functionality ... so fair to charge the current task for the whole activity. ... is some other memory hungry application which is forcing these swap outs. ...
    (Linux-Kernel)