Re: [PATCH 02/10] mm: system wide ALLOC_NO_WATERMARK

From: Christoph Lameter
Date: Tue Aug 07 2007 - 18:19:46 EST


On Mon, 6 Aug 2007, Daniel Phillips wrote:

> > AFAICT: This patchset is not throttling processes but failing
> > allocations.
>
> 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.

See the code added to slub: Allocations are satisfied from the reserve
patch or they are failing.

> > The patchset does not reconfigure the memory reserves as
> > expected.
>
> What do you mean by that? Expected by who?

What would be expected it some recalculation of min_freekbytes?

> > And I suspect that we
> > have the same issues as in earlier releases with various corner cases
> > not being covered.
>
> Do you have an example?

Try NUMA constraints and zone limitations.

> > Code is added that is supposedly not used.
>
> What makes you think that?

Because the argument is that performance does not matter since the code
patchs are not used.

> > If it ever is on a large config then we are in very deep trouble by
> > the new code paths themselves that serialize things in order to give
> > some allocations precendence over the other allocations that are made
> > to fail ....
>
> You mean by allocating the reserve memory on the wrong node in NUMA?

No I mean all 1024 processors of our system running into this fail/succeed
thingy that was added.

> That is on a code path that avoids destroying your machine performance
> or killing the machine entirely as with current kernels, for which a

As far as I know from our systems: The current kernels do not kill the
machine if the reserves are configured the right way.

> 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.

There is your problem. The justification is not clear at all and the
solution likely causes unrelated problems.



-
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/