Messages in this thread | | | Subject | Re: [Linux-fbdev-devel] Re: [ACPI] inappropriate use of in_atomic() | From | Benjamin Herrenschmidt <> | Date | Sat, 12 Mar 2005 11:22:54 +1100 |
| |
On Fri, 2005-03-11 at 16:13 -0800, Andrew Morton wrote: > (where'd my cc go?) > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > > > On Fri, 2005-03-11 at 01:46 -0800, Andrew Morton wrote: > > > Jan Kasprzak <kas@fi.muni.cz> wrote: > > > > > > > > This may be the cause of > > > > > > > > http://bugme.osdl.org/show_bug.cgi?id=4150 > > > > > > Looks that way, yes. > > > > Note that it would be interesting to fix that (I mean the reliability of > > is_atomic() or an alternative). I agree it's quite bad to rely on that > > in practice, but there are a few corner cases where it's useful (like > > oops handling in fbdev's etc...) > > > > That would require that we increment current->something on every > spin/read/write_lock and decrement it in unlock, even with !CONFIG_PREEMPT. > > iirc, Anton added an option to do that to the ppc64 build, decoupled from > CONFIG_PREEMPT (which ppc64 doesn't support).
ppc64 _does_ support PREEMPT nowadays :)
> But it's an appreciable amount of overhead. -- Benjamin Herrenschmidt <benh@kernel.crashing.org>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |