On Monday 06 August 2007 16:14, Christoph Lameter wrote:
Here is one user:
http://zumastor.googlecode.com/svn/trunk/ddsnap/kernel/dm-ddsnap.c
down(&info->throttle_sem);
Peter has another (swap over net). A third is the network stack itself,
which is in the full patch set that Peter has posted a number of times
in the past but did not appear today because Peter broke the full patch
set up into multiple sets to make it all easier to understand.
Failing allocations? Where do you see that? As far as I can see,
Peter's patch set allows allocations to fail exactly where the user has
always specified they may fail, and in no new places. If there is a
flaw in that logic, please let us know.
What the current patch set actually does is allow some critical
allocations that would have failed or recursed into deadlock before to
succeed instead, allowing vm writeout to complete successfully. You
may quibble with exactly how he accomplishes that, but preventing these
allocations from failing is not optional.
What do you mean by that? Expected by who?
Peter did not actually have to add a new layer of abstraction to
alloc_pages to impose order on the hardcoded hacks that currently live
in there to decide how far various callers can dig into reserves. It
would probably help people understand this patch set if that part were
taken out for now and replaced with the original seat-of-the-pants two
line hack I had in the original. But I do not see anything wrong with
what Peter has written there, it just takes a little more time to read.
Do you have an example?
What makes you think that?
You mean by allocating the reserve memory on the wrong node in NUMA?
That is on a code path that avoids destroying your machine performance
or killing the machine entirely as with current kernels, for which a
few cachelines pulled to another node is a small price to pay. And you
are free to use your special expertise in NUMA to make those fallback
paths even more efficient, but first you need to understand what they
are doing and why.
At your service for any more questions :-)
Regards,
Daniel
-
