Messages in this thread | | | Date | Wed, 18 Jan 2012 09:10:29 -0800 | From | Tejun Heo <> | Subject | Re: Kernel crash in icq_free_icq_rcu |
| |
Hello, Vivek.
On Wed, Jan 18, 2012 at 11:36:38AM -0500, Vivek Goyal wrote: > Not calling ioscheduler during plug merge will allow merging of sync/async > requests together. I guess we wouldn't want that. The only check we can > skip in case of plug merge, is whether bio and rq beong to same task/cfqq > or not. > > May be separate elevator functions for plug merge (without lock) and > elevator merge (with lock) will do?
I don't think so. As I wrote before, plugging is about issuing, not scheduling. In a sense, it's a block layer service to upper layers to make building larger request easier such that block layer users can do "plug - issue multiple bios of whatever size - flush" instead of having to manually build series of maximum sized bios. As such, bios submitted during a single plugging fare naturally expected to be for the same purpose. They all belong to single IO unit after all.
Note that although request is involved in plug merging, the request isn't known to elevator (other than set_request(), that is). The only reason we go half-way through request issuing, stash request, do plug merging and then do the rest on flush is because block layer doesn't have a way to deal with arbitrarily sized bios. We're piggy backing on request merge logic because that's the only way we know how to group bios.
In the long run, I think plugging should be done with bios. There's no reason to care about requests at that level. We're just collecting bios issued as a unit and are likely to be close to each other. If request_queue can deal with arbitrarily sized bios (and list of them), we can simply collect bios and flush down on unplug. This would be much cleaner, make plugging useable for bio based drivers and allow simplifying stacking drivers.
Thanks.
-- tejun
| |