Messages in this thread Patch in this message | | | Date | Thu, 18 Mar 2004 20:27:07 +0100 | From | Jens Axboe <> | Subject | Re: 2.6.4-mm2 |
| |
On Thu, Mar 18 2004, Andrew Morton wrote: > > Comparing one pair of readprofile results, I find it curious that > > dm_table_unplug_all and dm_table_any_congested show up near the top of a > > 2.6.4-mm2 profile when they haven't shown up before in 2.6.3. > > 14015190 poll_idle 241641.2069 > 175162 generic_unplug_device 1317.0075 > 165480 __copy_from_user_ll 1272.9231 > 161151 __copy_to_user_ll 1342.9250 > 152106 schedule 85.0705 > 142395 DAC960_LP_InterruptHandler 761.4706 > 113677 dm_table_unplug_all 1386.3049 > 65420 __make_request 45.5571 > 64832 dm_table_any_congested 697.1183 > 37913 try_to_wake_up 32.2939 > > That's broken. How many disks are involve in the DM stack? > > The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed > this, but I cannot immediately explain what you're seeing here.
Ugh that looks really bad, I wonder how it could possibly ever be this bad. Mark, please do do a run with 2.6.5-rc1-mm2, I'd very much like to see the profile there. If things get this bad, I need to think some more about how to best handle the 'when to invoke request_fn on unplug calls' logic again.
Actually, please also do a run with 2.6.5-rc1-mm2 + inlined patch. For non-stacked dm on dm it should work and could make a lot of difference for you.
--- drivers/block/ll_rw_blk.c~ 2004-03-18 20:26:17.088531084 +0100 +++ drivers/block/ll_rw_blk.c 2004-03-18 20:26:44.773554953 +0100 @@ -1134,11 +1134,8 @@ if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) return; - /* - * always call down, since we can race now with setting the plugged - * bit outside of the queue lock - */ - blk_remove_plug(q); + if (!blk_remove_plug(q)) + return; /* * was plugged, fire request_fn if queue has stuff to do -- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |