Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jan 2003 10:39:59 -0500 (EST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        arch@FreeBSD.ORG, Andrew Gallatin <gallatin@cs.duke.edu>
Subject:   Re: M_ flags summary.
Message-ID:  <XFMail.20030123103959.jhb@FreeBSD.org>
In-Reply-To: <1043324803.28337.40.camel@builder02.qubesoft.com>

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

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.  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.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.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?XFMail.20030123103959.jhb>