Date: 23 Jan 2003 12:26:43 +0000 From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <1043324803.28337.40.camel@builder02.qubesoft.com> In-Reply-To: <XFMail.20030122165805.jhb@FreeBSD.org> References: <XFMail.20030122165805.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2003-01-22 at 21:58, John Baldwin wrote:
> On 22-Jan-2003 Andrew Gallatin wrote:
> >
> >
> > Speaking as the token 3rd party driver vendor, the removal of
> > M_WAITOK/M_TRYWAIT is irritating, but not something that can't be
> > solved with yet another ifdef in my driver. Breaking the 5.0 ABI
> > prior to 5.1 is no big deal to me, as I don't plan to support
> > 5.0-RELEASE anyway, so I don't care what the #defines end up as in the
> > 5.0-STABLE branch.
> >
> > My thoughts are that whether we pronounce it po-ta-to, or po-tat-o,
> > its still a potato and how its pronounced doesn't matter nearly as
> > much as how it tastes.
> >
> > 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.
>
> We already do this for malloc(), that is the source of most of the
> 'could sleep' messages these days. I have some patches I need to
> commit to make the actual message more informative so that it will
> say 'could malloc' etc.
I was thinking yesterday that perhaps it would be useful to have a new
entry point to the allocator. This might be called mmalloc, with the
idea that mmalloc is to malloc as msleep is to tsleep. The caller would
call it with its currently held mutex as an argument and that mutex
would filter all the way down to the place where malloc sleeps and be
passed to msleep (or something).
This makes it explicit for the caller what is happening, i.e. it is
clear that as a side effect of calling the allocator, your mutex may be
released and regained so you need to take care about any cached results
depending on variables which might be modified by other threads.
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?1043324803.28337.40.camel>