* Randell Jesup <[EMAIL PROTECTED]> [010117 08:14] wrote:
> >It seems Alfred Perlstein wrote:
> >> I have a patch here that removes await/asleep from the kernel API.
> >> 
> >> http://people.freebsd.org/~alfred/noasleep.diff
> >> 
> >> Matt Dillon implemented alseep/await quite some time ago and the
> >> only thing that's using it is ata.  In order to clean up some of
> >> the schduler and vm system I'm removing support for it.
> >> 
> >> Peter Wemm and I suspect that ata doesn't need it.  Right now I'm
> >> running several make -j128 buildworlds and buildkernels with this
> >> patch to catch any ata problems.
>         Ummmm...
>         It seems to me from reading the man page for asleep/await that
> they have significant utility, and that the real issue would be one of
> code not using them, especially as people work to remove the Giant
> lock for SMP.
>         Or is the discussion in the man page wrong in some way?

The manpage is correct, but we've yet to see it used properly in
the code with the exception of ata, and even with ata we're not
sure if it's needed.

Basically the idea is that at a certain depth into the kernel you
start using the M_AWAIT parameter when requesting certain resources.
Since that removes the possiblity of blocking you can feel safe holding
a mutex over these lower parts of the code, then only releasing your
mutex later.  If a resource shortage is detected then you can call
await and retry later.

1) from sleep(9):

     to actually wait for the previously queued wait condition.  If asleep()
     is called several times, only the most recent call is effective.
     asleep() may be called with an ident value of NULL to remove any previ-
     ously queued condition.

Basically, there's a chance you may clobber previous calls to asleep,
this is somewhat unlikely since most shortages or blocking when 
some 'NOBLOCK' flag is passed in should immediately return.

Somewhat of a concern, but it really is unlikely to be a problem.

2) most things you'd use mawait for would be under a lock already,
since it's under a lock, you must context switch anyway, there's
no "optimized out" sleep, because first the interrupt will block
on your mutex, then you'll get to run, when you drop your mutex
the interrupt will then run.  If you do this with msleep or masleep
the effect is the same.

3) no one uses it! :)

4) most anything you need asleep for could probably be done with

I'm not going to axe it for a few days, this is a really amazing
API that Matt added, the problem is utility and useage over code

It's just a proposal.

"I have the heart of a child; I keep it in a jar on my desk."

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to