[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgtzJPa7XJ5Ozdhf@alley>
Date: Tue, 15 Feb 2022 10:32:20 +0100
From: Petr Mladek <pmladek@...e.com>
To: Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>
Cc: John Ogness <john.ogness@...utronix.de>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Marco Elver <elver@...gle.com>,
Stephen Boyd <swboyd@...omium.org>,
Alexander Potapenko <glider@...gle.com>,
Randy Dunlap <rdunlap@...radead.org>,
Nicholas Piggin <npiggin@...il.com>
Subject: Re: [PATCH printk v1 01/13] printk: rename cpulock functions
On Fri 2022-02-11 22:04:48, Peter Zijlstra wrote:
> On Fri, Feb 11, 2022 at 03:57:27PM -0500, Steven Rostedt wrote:
> > On Fri, 11 Feb 2022 15:48:08 +0106
> > John Ogness <john.ogness@...utronix.de> wrote:
> >
> > > It is because (as in the example above), taking this "lock" does not
> > > provide synchronization to data. It is only synchronizing between
> > > CPUs. It was Steven's suggestion to call the thing a cpu_sync object and
> > > nobody in the RT Track seemed to disagree.
> >
> > I love causing trouble ;-)
> >
> > Actually, it wasn't just my suggestion. IIRC, I believe Peter Zijlstra was
> > against calling it a lock (Peter, you can use lore to see the context here).
>
> All I remember is that it was in a room and I was late, I can't even
> remember what City we were all in at the time. Was this Lisbon?
>
> Anyway, as Steve said, it isn't really a strict exclusion thing, it only
> avoids the most egregious inter-cpu interleaving. I'm down with
> goldi-locks, something has to have that name :-)
You troublemakers :-)
OK, I know, I am the troublemaker here.
Best Regards,
Petr
Powered by blists - more mailing lists