if (!cfqq) { + spin_unlock_irq(cfqd->queue->queue_lock); cfqq = mempool_alloc(cfq_mpool, GFP_NOIO); + spin_lock_irq(cfqd->queue->queue_lock);
hmm, any reason to get the lock here and not later on, when you initialized the cfqq?
Looks like he is releasing and getting the lock on cfqd (note
the 'd' at the
end) and not cfqq.
yep, saw that, but no need to reacquire it _before_ the cfqq initialization is complete ...
Agreed.
Marc
The patch is screwed up. I'm seeing erratic behaviour (I/O ops don't complete, system eventually hangs) with it turned on (this is without loading CKRM). Eliminating the lock/unlock makes the system responsive again.
The reason could have to do with the "class" queue (cfqq) getting allocated on each request (potentially). So the there's a chance of two allocations being attempted if cfqd->queue->queue_lock is not being held. Hence the retry allocation code in 2.6.8.1 cfq-iosched's __cfq_get_queue.
So the retry needs to go in as well...will create/test and send it out if it works.
Shailabh
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
