Date: Thu, 25 May 2006 23:59:34 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu Cc: cvs-src@freebsd.org, scottl@samsco.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/syscons/apm apm_saver.c src/sys/i386/bios apm.c apm.h Message-ID: <20060525.235934.-1956306548.imp@bsdimp.com> In-Reply-To: <20060526055424.GG49081@funkthat.com> References: <44766F75.9060100@samsco.org> <20060525.220611.74708877.imp@bsdimp.com> <20060526055424.GG49081@funkthat.com>
index | next in thread | previous in thread | raw e-mail
In message: <20060526055424.GG49081@funkthat.com>
John-Mark Gurney <gurney_j@resnet.uoregon.edu> writes:
: Warner Losh wrote this message on Thu, May 25, 2006 at 22:06 -0600:
: > > In the past, I've been against mandating that callouts/timeouts/generic
: > > taskqueues should not be allowed to sleep. However, after looking over
: > > the history of this problem as well as others, it seems that it's just
: > > too easy for driver authors to make bad assumptions and wind up with a
: > > priority inversion/deadlock like this. It would be relatively trivial
: > > to mark these contexts as being non-sleepable and have the msleep code
: > > enforce it, like is done with ithreads. What do you think? Anyways,
: > > thanks for looking at this and fixing it.
: >
: > At the very least, we should mandate that timeouts are a non-sleepable
: > event. Sleeping just doesn't work there. taskqueues, I'm less sure
: > of, since short sleeps there work, but do degrade performance. I like
: > this idea.
:
: People worried about things like this should create their own thread
: for their taskqueue.. It's quite easy (simple macro declaration), and
: I did that for handling kq in kq...
The problem isn't people that are worried about these things... It is
those that don't worry about them..
Warner
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060525.235934.-1956306548.imp>