On Thursday January 10, dan.j.williams@xxxxxxxxx wrote: > On Jan 10, 2008 12:13 AM, dean gaudet <dean@xxxxxxxxxx> wrote: > > w.r.t. dan's cfq comments -- i really don't know the details, but does > > this mean cfq will misattribute the IO to the wrong user/process? or is > > it just a concern that CPU time will be spent on someone's IO? the latter > > is fine to me... the former seems sucky because with today's multicore > > systems CPU time seems cheap compared to IO. > > > > I do not see this affecting the time slicing feature of cfq, because > as Neil says the work has to get done at some point. If I give up > some of my slice working on someone else's I/O chances are the favor > will be returned in kind since the code does not discriminate. The > io-priority capability of cfq currently does not work as advertised > with current MD since the priority is tied to the current thread and > the thread that actually submits the i/o on a stripe is > non-deterministic. So I do not see this change making the situation > any worse. In fact, it may make it a bit better since there is a > higher chance for the thread submitting i/o to MD to do its own i/o to > the backing disks. > > Reviewed-by: Dan Williams <dan.j.williams@xxxxxxxxx> Thanks. But I suspect you didn't test it with a bitmap :-) I ran the mdadm test suite and it hit a problem - easy enough to fix. I'll look out for any other possible related problem (due to raid5d running in different processes) and then submit it. Thanks, NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
