Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 17:56:00 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Andrew Gallatin <gallatin@cs.duke.edu>, arch@FreeBSD.ORG
Subject:   Re: M_ flags summary.
Message-ID:  <20030122175600.A77460@unixdaemons.com>
In-Reply-To: <20030122215424.GV42333@elvis.mu.org>; from bright@mu.org on Wed, Jan 22, 2003 at 01:54:24PM -0800
References:  <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu> <20030122215424.GV42333@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, Jan 22, 2003 at 01:54:24PM -0800, Alfred Perlstein wrote:
> * Andrew Gallatin <gallatin@cs.duke.edu> [030122 13:43] wrote:
> > 
> > The taste "problem" here is that it always used to be safe to sleep
> > in a process context.  That's not true anymore.  Now its safe to
> > sleep in a process context if you're not holding any mutexes.  So
> > there are pleny of sleepable allocation bugs lurking.
> > 
> > If we want to catch sleepable allocation bugs right up front, I
> > suggest we put this:
> > 
> > if (!(flags & M_NOWAIT)) {
> >    WITNESS_SLEEP(1, NULL);
> > }
> > 
> > at the top of malloc, and at the top of all entry points to the mbuf
> > allocator.  Eg, before the system has a chance to pull the allocation 
> > off of some cache which will succeed 99.5% of the time, except when
> > the system is under memory pressure.
> > 
> > Sorry for dragging this in another direction..
> 
> This is actually a very good idea.  It's too bad that one needs witness
> to catch this though.  Can you add it, or shall i do it tonight?

  It would be great if you did this for the mbuf code (the malloc()
  code apparently, as John points out, already does it).  If anything, I
  think this is the one valuable thing we got out of this discussion.

> -- 
> -Alfred Perlstein [alfred@freebsd.org]
> 'Instead of asking why a piece of software is using "1970s technology,"
>  start asking why software is ignoring 30 years of accumulated wisdom.'

-- 
Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122175600.A77460>