Hi Zach! Thanks for the responses. -- On Tue, 2 Oct 2007, Zach Brown wrote: > > On Oct 1, 2007, at 1:39 PM, Peter Zijlstra wrote: > > > > > On Mon, 2007-10-01 at 12:52 -0700, Zach Brown wrote: > > > >> Do you have any suggestions for locking constructs that RT would > >> prefer? > > > > Basically, anything that maps to a simple mutex. Anything more complex > > gets real messy real quick. > > I'm worried that the aio+dio implementation of concurrent pending IOs > just doesn't map well to PI. > > Would a hack with a mutex and counts help at all? It seems like it > would still have the same problem. The count increments don't > transfer ownership to the count decrements and the wake up. > > io submission from tasks: > down(&inode->i_mutex); > atomic_inc(&inode->in_flight); > up(&inode->i_mutex); > > io completion from interrupts: > if(atomic_dec_and_test(&inode->in_flight)) > wake_up(&inode->waiting); > > file allocation in tasks: > down(&inode->i_mutex); > wait_event(inode->waiting, atomic_read(&inode->in_flight) == 0); > up(&inode->i_mutex); > > (yeah, yeah, starvation -- it's just a demonstration) This looks more like a completion. Actually, completions don't have PI either, but they are usually OK. > > In any case, this seems like it's not a very high priority now that > RT has Steven's work-around. If it does become a priority can you > guys let linux-fsdevel know? Actually, it may still be a high priority. We have one BUG currently that seems to trigger starvation. But we don't know yet if it's a bug in the test or in the FS code yet. I don't know the full details yet, but we do have someone currently looking at it. These tests are what found this issue in the first place. When more info becomes available, I will definitely CC the linux-fsdevel list. Thanks for letting me know about it. (I usually get confused by all the different lists that are out there). -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
