linux-kernel - Re: [PATCH [RT] 11/14] optimize the !printk fastpath through the lock acquisition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <47BD64D0.BA47.005A.0@novell.com>
Date:	Thu, 21 Feb 2008 09:47:28 -0700
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	<a.p.zijlstra@...llo.nl>, <mingo@...e.hu>, <bill.huey@...il.com>,
	<rostedt@...dmis.org>, <kevin@...man.org>, <tglx@...utronix.de>,
	<cminyard@...sta.com>, <dsingleton@...sta.com>,
	<dwalker@...sta.com>, "Moiz Kohari" <MKohari@...ell.com>,
	"Peter Morreale" <PMorreale@...ell.com>,
	"Sven Dietrich" <SDietrich@...ell.com>, <dsaxena@...xity.net>,
	<gregkh@...e.de>, <npiggin@...e.de>,
	<linux-kernel@...r.kernel.org>, <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH [RT] 11/14] optimize the !printk fastpath through
	the lock acquisition

>>> On Thu, Feb 21, 2008 at 11:36 AM, in message <200802211736.26719.ak@...e.de>,
Andi Kleen <ak@...e.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/