Re: Freeze

On Tue, Dec 28, 2004 at 01:24:01PM -0500, Jeff Roberson wrote:
> On Mon, 27 Dec 2004, Bosko Milekic wrote:
> 
> >
> > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=159278+0+current/freebsd-current
> >
> > (and see previous in thread for context).
> >
> > Let's hope.
> 
> It might be better for the slab zones to msleep there rather than flood
> the system with allocation requests.  Imagine if many threads were to hit
> this code path, the slabzone would get a new slab for each calling thread,
> when really we only want one more.

  They will not flood the system with allocation requests.  They
  will merely block in the VM if they need to (if the allocation is
  M_WAITOK, otherwise they will return NULL shortly thereafter).
  This is because after that check, in uma_zalloc_internal(), we enter
  the loop which performs a slab_zalloc() call (which dips into VM).
  The dipping into VM will not occur repeatedly, but only once, as it is
  supposed to; the change merely gives it a chance to do so.

  The uk_recurse check was designed to protect from recursion occuring
  from the VM itself and so should not prevent multiple threads from
  dipping into the VM, even if it is for the same zone.

  This is perhaps an implementation flaw (but it is separate), that
  under a starvation situation you might have two or more separate
  threads ask the VM for pages (when in fact only one slab needs to be
  allocated to satisfy N requests), but this scenario is rare and is in
  my opinion not worth changing the implementation for (in that kind of
  long-term starvation, you're likely facing serious problems that UMA
  alone cannot address anyway). 

> It seems like this bug should have been caught sooner with asserts rather
> than a hang somewhere.  Can you investigate why this did not happen?

  I don't see why the bug would have been hit sooner.  The likelihood of
  another allocation request coming in through uma_zalloc_internal()
  _exactly_ when another is allocating a slab header within the window
  where uk_recurse > 0 is small.

-- 
Bosko Milekic
bmilekic_at_technokratis.com
bmilekic_at_FreeBSD.org