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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080225220313.GG2659@elf.ucw.cz>
Date:	Mon, 25 Feb 2008 23:03:13 +0100
From:	Pavel Machek <pavel@....cz>
To:	Gregory Haskins <ghaskins@...ell.com>
Cc:	mingo@...e.hu, a.p.zijlstra@...llo.nl, tglx@...utronix.de,
	rostedt@...dmis.org, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, bill.huey@...il.com,
	kevin@...man.org, cminyard@...sta.com, dsingleton@...sta.com,
	dwalker@...sta.com, npiggin@...e.de, dsaxena@...xity.net,
	ak@...e.de, acme@...hat.com, gregkh@...e.de, sdietrich@...ell.com,
	pmorreale@...ell.com, mkohari@...ell.com
Subject: Re: [(RT RFC) PATCH v2 5/9] adaptive real-time lock support

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?

> +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).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/