Thread (12 messages) 12 messages, 3 authors, 2006-12-08

Re: Worst case performance of up()

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2006-12-04 20:25:58

On Mon, 2006-12-04 at 13:43 +0000, Adrian Cox wrote:
On Sun, 2006-12-03 at 07:52 +1100, Benjamin Herrenschmidt wrote:
quoted
On Sat, 2006-12-02 at 11:54 +0000, Adrian Cox wrote:
quoted
On Sat, 2006-12-02 at 22:15 +1100, Benjamin Herrenschmidt wrote:
quoted
I think we are hitting a livelock due to both CPUs trying to perform an
atomic operation on the same cache line (or same variable even).
I agree.
I now have this one identified and fixed. The cure is actually simple:
on 32-bit SMP machines, rather than setting powersave_nap to 0, set
ppc_md.power_save to NULL.

CPU A is attempting to reschedule the idle thread on CPU B:
set_tsk_thread_flag(p, TIF_NEED_RESCHED);

CPU B is in the idle loop, but does not support nap. The result is that
ppc6xx_idle() returns immediately, and CPU B runs in a tight loop:
while(...) {
	set_thread_flag(TIF_POLLING_NRFLAG);
	...
	clear_thread_flag(TIF_POLLING_NRFLAG);
}

If ppc_md.power_save is NULL, then the idle loop does not touch the flag
word of the idle thread, and everything works.
Good to know, there might be other cases of performance issues due to
touching that flag in a loop...

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help