Re: [PATCH 3/2] dm: table load must always try dm_setup_md_queue

[Kiyoshi Ueda <k-ueda@ct.jp.nec.com>]

Hi Mike,

On 06/09/2010 05:53 PM +0900, Mike Snitzer wrote:
> On Wed, Jun 09 2010 at  1:38am -0400, Kiyoshi Ueda wrote:
>> On 06/05/2010 05:15 AM +0900, Mike Snitzer wrote:
>>> @@ -2164,7 +2164,8 @@ static int dm_init_request_based_queue(s
>>>  {
>>>  	struct request_queue *q = NULL;
>>>  
>>> -	BUG_ON(md->queue->elevator);
>>> +	if (unlikely(md->queue->elevator))
>>> +		return 1;
>> 
>> I think the "unlikely" should be rather "likely", since
>> dm_init_request_based_queue() is now called whenever request-based
>> table is loaded even after the actual initialization has been done.
> 
> Yes, good point.  Though I'd expect reloading a request-based table is
> actually fairly rare.  Is it really all that worthwhile to have any
> branch prediction here?  Should we just remove the likely/unlikely
> entirely?

For multipath, table reloading happens when path connection state is
changed (e.g. link-up => link-down), since if a path state becomes down,
the device for the path disappears and multipath configuration is changed.

Although I'm not sure "it's actually fairly rare", I believe it's rare.
So I don't object to remove the branch prediction.

Thanks,
Kiyoshi Ueda