On Mon, Mar 04 2002, Peter Osterlund wrote:
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.
I would consider this bandaid... Yet another reason for making the lower levels issue the actual flush, then there is no need for you to synchronize the flush from the pktcdvd level. -- Jens Axboe