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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
