[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101216173430.GA12841@redhat.com>
Date: Thu, 16 Dec 2010 18:34:30 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Chris Mason <chris.mason@...cle.com>,
Frank Rowand <frank.rowand@...sony.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Mike Galbraith <efault@....de>, Paul Turner <pjt@...gle.com>,
Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 2/5] mutex: Use p->oncpu for the adaptive spin
On 12/16, Peter Zijlstra wrote:
>
> @@ -3867,52 +3866,29 @@ int mutex_spin_on_owner(struct mutex *lo
> * DEBUG_PAGEALLOC could have unmapped it if
> * the mutex owner just released it and exited.
> */
> - if (probe_kernel_address(&owner->cpu, cpu))
> + if (probe_kernel_address(&owner->oncpu, oncpu))
> return 0;
> #else
> - cpu = owner->cpu;
> + oncpu = owner->oncpu;
> #endif
>
> - /*
> - * Even if the access succeeded (likely case),
> - * the cpu field may no longer be valid.
> - */
> - if (cpu >= nr_cpumask_bits)
> - return 0;
> -
> - /*
> - * We need to validate that we can do a
> - * get_cpu() and that we have the percpu area.
> - */
> - if (!cpu_online(cpu))
> + if (!oncpu)
> return 0;
>
> - rq = cpu_rq(cpu);
> -
> - for (;;) {
> - /*
> - * Owner changed, break to re-assess state.
> - */
> - if (lock->owner != owner) {
> - /*
> - * If the lock has switched to a different owner,
> - * we likely have heavy contention. Return 0 to quit
> - * optimistic spinning and not contend further:
> - */
> - if (lock->owner)
> - return 0;
> - break;
> - }
> -
> - /*
> - * Is that owner really running on that cpu?
> - */
> - if (task_thread_info(rq->curr) != owner || need_resched())
> + while (lock->owner == owner && owner->oncpu) {
It seems, this owner->oncpu dereference needs probe_kernel_address() too.
Of course, only in theory.
OTOH, I do not understand why we need the first "if (!oncpu)" check
(and "int oncpu" at all).
Oleg.
--
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/
Powered by blists - more mailing lists