On Thu, Apr 08 2010, Jeff Moyer wrote: > Jens Axboe <jens.axboe@xxxxxxxxxx> writes: > > > Precisely. The next question would be how to control the yielding. In > > this particular case, you want to be yielding to a specific cfqq. IOW, > > you essentially want to pass your slide on to that queue. The way the > > above is implemented, you could easily just switch to another unrelated > > queue. And if that is done, fairness is skewed without helping the > > yielding process at all (which was the intention). > > Well, that's true in part. Prior to this patch, the process would idle, > keeping all other cfq_queues on the system from making progress. With > this patch, at least *somebody* else makes progress, getting you closer > to running the journal thread that you're blocked on. Ideally, you'd > want the thread you're waiting on to get disk time next, sure. You > would have to pass the process information down to the I/O scheduler for > that, and I'm not sure that the file system code knows which process to > hand off to. Does it? > > Do we really want to go down this road at all? I'm not convinced. Don't get me wrong, neither am I. I'm just thinking out loud and pondering. As a general mechanism, yield to a specific cfqq is going to be tricky and doing a generic yield to signal that _someone_ else must make progress before we can is better than nothing. Continuing that train of thought, I don't think we'll ever need full 'yield to X' functionality where 'X' is a really specific target. But for this fsync case, we know at least what we are yielding to and it seems like a shame to throw away that information. So you could include a hint of what to yield to, which cfq could factor in. Dunno, I need to think a bit about the cleanliness of such an approach. We can definitely use your patch as a starting point. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
