On Mon, 4 Mar 2002, Jens Axboe wrote:
On Sun, Mar 03 2002, Peter Osterlund wrote:
The interesting change in this version is that I have changed the way mixing of read and write requests is handled. The driver now inserts a "synchronize cache" command before the first read command following a write command. This has three advantages:
... BTW, what is the cache_sync_mutex good for?! AFAICS, we don't need to serialize this from the pktcdvd view point, and the cd drivers will serialize special commands on its own. unflushed_writes does need a barrier at least, but I'd rather see that be a bit flag instead. A block mutex for a simple variable is quite costly and risks schedule storms.
Without the mutex the cache sync command didn't always end up between the write and the read. I think this scenario can happen: 1. pkt_make_request is called with a read request. 2. unflushed_writes is 0, so no cache sync is generated. 3. pkt_make_request remaps the read and __make_request in ll_rw_blk.c is called. This function calls __get_request_wait which sleeps. 4. The kcdrwd thread is woken up and injects a new write request. 5. __make_request continues and inserts the read request immediately following the write request. Besides, in an SMP environment, couldn't pkt_make_request execute at the same time as the kcdrwd thread? Maybe I misunderstood what was really happening, but I do know that without the mutex, the sync command wasn't always inserted at the right place in the request queue. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340