Messages in this thread | | | From | Nick Piggin <> | Subject | Re: [patch] SLQB slab allocator | Date | Thu, 5 Feb 2009 14:14:38 +1100 |
| |
On Thursday 05 February 2009 07:10:31 Christoph Lameter wrote: > On Tue, 3 Feb 2009, Pekka Enberg wrote: > > Well, the slab_hiwater() check in __slab_free() of mm/slqb.c will cap > > the size of the queue. But we do the same thing in SLAB with > > alien->limit in cache_free_alien() and ac->limit in __cache_free(). So > > I'm not sure what you mean when you say that the queues will "grow > > unconstrained" (in either of the allocators). Hmm? > > Nick said he wanted to defer queue processing. If the water marks are > checked and queue processing run then of course queue processing is not > deferred and the queue does not build up further.
I don't think I ever said anything as ambiguous as "queue processing". This subthread was started by your concern of periodic queue trimming, and I was definitely talking about the possibility to defer *that*.
| |