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