Date: 23 Jan 2003 16:35:38 +0000 From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: M_ flags summary. Message-ID: <1043339738.29341.1.camel@builder02.qubesoft.com> In-Reply-To: <XFMail.20030123103959.jhb@FreeBSD.org> References: <XFMail.20030123103959.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2003-01-23 at 15:39, John Baldwin wrote:
> On 23-Jan-2003 Doug Rabson wrote:
> > 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.
>
> This would prevent the malloc implementation from using internal mutexes
> that it msleep's or cv_wait's on. You only get to pass in one mutex
> to cv_wait* and msleep.
That did occur to me too, which was why I wrote "or something". It looks
hard to DTRT here without a version of msleep which took a list of
mutexes to release.
> In my experience, one can often "fix" problems
> with holding locks across malloc() by malloc()'ing things earlier in the
> function before you need locks.
This is obviously preferable.
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?1043339738.29341.1.camel>