On Mon, 14 May 2007, Peter Zijlstra wrote:
> On Mon, 2007-05-14 at 09:29 -0700, Christoph Lameter wrote:
> > On Mon, 14 May 2007, Matt Mackall wrote:
> >
> > > privileged thread unprivileged greedy process
> > > kmem_cache_alloc(...)
> > > adds new slab page from lowmem pool
> >
> > Yes but it returns an object for the privileged thread. Is that not
> > enough?
>
> No, because we reserved memory for n objects, and like matt illustrates
> most of those that will be eaten by the greedy process.
> We could reserve 1 page per object but that rather bloats the reserve.
1 slab per object not one page. But yes thats some bloat.
You can pull the big switch (only on a SLUB slab I fear) to switch
off the fast path. Do SetSlabDebug() when allocating a precious
allocation that should not be gobbled up by lower level processes.
Then you can do whatever you want in the __slab_alloc debug section and we
wont care because its not the hot path.
SLAB is a bit different. There we already have issues with the fast path
due to the attempt to handle numa policies at the object level. SLUB fixes
that issue (if we can avoid you hot path patch). It intentionally does
defer all special object handling to the slab level to increase NUMA
performance. If you do the same to SLAB then you will get the NUMA
troubles propagated to the SMP and UP level.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
