Re: [PATCH [RT] 11/14] optimize the !printk fastpath throughthe lock acquisition

From: Gregory Haskins
Date: Thu Feb 21 2008 - 11:54:31 EST


>>> On Thu, Feb 21, 2008 at 11:36 AM, in message <200802211736.26719.ak@xxxxxxx>,
Andi Kleen <ak@xxxxxxx> wrote:
> On Thursday 21 February 2008 16:27:22 Gregory Haskins wrote:
>
>> @@ -660,12 +660,12 @@ rt_spin_lock_fastlock(struct rt_mutex *lock,
>> void fastcall (*slowfn)(struct rt_mutex *lock))
>> {
>> /* Temporary HACK! */
>> - if (!current->in_printk)
>> - might_sleep();
>> - else if (in_atomic() || irqs_disabled())
>> + if (unlikely(current->in_printk) && (in_atomic() || irqs_disabled()))
>
> I have my doubts that gcc will honor unlikelies that don't affect
> the complete condition of an if.
>
> Also conditions guarding returns are by default predicted unlikely
> anyways AFAIK.
>
> The patch is likely a nop.
>

Yeah, you are probably right. We have found that the system is *extremely* touchy on how much overhead we have in the lock-acquisition path. For instance, using a non-inline version of adaptive_wait() can cost 5-10% in disk-io throughput. So we were trying to find places to shave anywhere we could. That being said, I didn't record any difference from this patch, so you are probably exactly right. It just seemed like "the right thing to do" so I left it in.

-Greg



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/