Re: 2.6.4-mm2

[Jens Axboe <axboe@suse.de>]

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