linux-kernel - Re: [(RT RFC) PATCH v2 5/9] adaptive real-time lock support

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 for Android: free password hash cracker in your pocket

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

Message-Id: <47C31B9E.BA47.005A.0@novell.com>
Date:	Mon, 25 Feb 2008 17:48:46 -0700
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Pavel Machek" <pavel@....cz>
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>,
	<acme@...hat.com>, <ak@...e.de>, <gregkh@...e.de>,
	<npiggin@...e.de>, <linux-kernel@...r.kernel.org>,
	<linux-rt-users@...r.kernel.org>
Subject: Re: [(RT RFC) PATCH v2 5/9] adaptive real-time lock support

>>> On Mon, Feb 25, 2008 at  5:03 PM, in message
<20080225220313.GG2659@....ucw.cz>, Pavel Machek <pavel@....cz> wrote: 
> Hi!
> 
>> +/*
>> + * Adaptive-rtlocks will busywait when possible, and sleep only if
>> + * necessary. Note that the busyloop looks racy, and it is....but we do
>> + * not care. If we lose any races it simply means that we spin one more
>> + * time before seeing that we need to break-out on the next iteration.
>> + *
>> + * We realize this is a relatively large function to inline, but note that
>> + * it is only instantiated 1 or 2 times max, and it makes a measurable
>> + * performance different to avoid the call.
>> + *
>> + * Returns 1 if we should sleep
>> + *
>> + */
>> +static inline int
>> +adaptive_wait(struct rt_mutex *lock, struct rt_mutex_waiter *waiter,
>> +	      struct adaptive_waiter *adaptive)
>> +{
>> +	int sleep = 0;
>> +
>> +	for (;;) {
>> +		/*
>> +		 * If the task was re-awoken, break out completely so we can
>> +		 * reloop through the lock-acquisition code.
>> +		 */
>> +		if (!waiter->task)
>> +			break;
>> +
>> +		/*
>> +		 * We need to break if the owner changed so we can reloop
>> +		 * and safely acquire the owner-pointer again with the
>> +		 * wait_lock held.
>> +		 */
>> +		if (adaptive->owner != rt_mutex_owner(lock))
>> +			break;
>> +
>> +		/*
>> +		 * If we got here, presumably the lock ownership is still
>> +		 * current.  We will use it to our advantage to be able to
>> +		 * spin without disabling preemption...
>> +		 */
>> +
>> +		/*
>> +		 * .. sleep if the owner is not running..
>> +		 */
>> +		if (!adaptive->owner->se.on_rq) {
>> +			sleep = 1;
>> +			break;
>> +		}
>> +
>> +		/*
>> +		 * .. or is running on our own cpu (to prevent deadlock)
>> +		 */
>> +		if (task_cpu(adaptive->owner) == task_cpu(current)) {
>> +			sleep = 1;
>> +			break;
>> +		}
>> +
>> +		cpu_relax();
>> +	}
>> +
>> +	put_task_struct(adaptive->owner);
>> +
>> +	return sleep;
>> +}
>> +
> 
> You want to inline this?

Yes.  As the comment indicates, there are 1-2 users tops, and it has a significant impact on throughput (> 5%) to take the hit with a call.  I don't think its actually much code anyway...its all comments.

> 
>> +static inline void
>> +prepare_adaptive_wait(struct rt_mutex *lock, struct adaptive_waiter 
> *adaptive)
> ...
>> +#define prepare_adaptive_wait(lock, busy) {}
> 
> This is evil. Use empty inline function instead (same for the other
> function, there you can maybe get away with it).

Ok.


> 									Pavel



--
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/