[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090217213256.GJ6761@linux.vnet.ibm.com>
Date: Tue, 17 Feb 2009 13:32:56 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Nick Piggin <npiggin@...e.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Jens Axboe <jens.axboe@...cle.com>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Rusty Russell <rusty@...tcorp.com.au>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Q: smp.c && barriers (Was: [PATCH 1/4] generic-smp: remove
single ipi fallback for smp_call_function_many())
On Tue, Feb 17, 2009 at 08:28:10PM +0100, Oleg Nesterov wrote:
> On 02/17, Nick Piggin wrote:
> >
> > How's this?
>
> To me, this patch makes the code much more clean/understandable.
>
> And imho it is very good it removes smp_read_barrier_depends()s
> which (I think) were just wrong.
>
>
> But I still have the question,
>
> > Does any architecture actually needs barriers? For the initiator I
> > could see it, but for the handler I would be surprised. The other
> > thing we could do for simplicity is just to require that a full
> > barrier is required before generating an IPI, and after receiving an
> > IPI. We can't just do that in generic code without auditing
> > architectures. There have been subtle hangs here on some archs in
> > the past.
>
> OK, so we add the barrier here:
>
> > @@ -104,6 +111,14 @@ void generic_smp_call_function_interrupt
> > int cpu = get_cpu();
> >
> > /*
> > + * Ensure entry is visible on call_function_queue after we have
> > + * entered the IPI. See comment in smp_call_function_many.
> > + * If we don't have this, then we may miss an entry on the list
> > + * and never get another IPI to process it.
> > + */
> > + smp_mb();
>
> But, any arch which needs this barrier should also call mb() in, say,
> smp_reschedule_interrupt() path. Otherwise we can miss TIF_NEED_RESCHED
> after return from the handler.
>
> So the question is: is there any arch which surely needs this barrier?
>
> IOW,
> int COND;
>
> void smp_xxx_interrupt(regs)
> {
> BUG_ON(!COND);
> }
>
> COND = 1;
> mb();
> smp_send_xxx(cpu);
>
> can we really hit the BUG_ON() above on some arch?
If all of the above is executed by the same task, tripping the BUG_ON()
means either a compiler or CPU bug.
Thanx, Paul
> (but in any case I agree, it is better to be safe and add the barrier
> like this patch does).
>
> 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