[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] waitqueue optimization, 2.4.0-test7

On Mon, 28 Aug 2000, Andrea Arcangeli wrote:

> Returning to your patch you're introducing an SMP race in the wait
> event interface. We enforced that wake_up had to provide an implicit
> memory barrier to avoid adding an explicit memory barrier in the
> middle of things like UnlockPage. [...]

yep, these are the cases i'm worried about as well. I thought that in all
cases where we use a waitqueue we do have some other synchronized object
as well (which administers the event/object we are waiting for) so in 99%
of the cases we dont rely on the synchronization of the wake_up() itself.
Isnt UnlockPage() atomic already (and a read/write barrier) to keep the
bits themselves consistent?

we have a number of other places that rely on clear_bit() being atomic -
if this isnt true anymore on Alpha then we could make it nonatomic on x86
as well - this would be a great micro-optimization eg. in the ext2fs code
[and other places]. We attempted this in early 2.3 but it was an obviously
broken thing.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.153 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site