[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgbPcAHgC1FLRXdR@hirez.programming.kicks-ass.net>
Date: Fri, 11 Feb 2022 22:04:48 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: John Ogness <john.ogness@...utronix.de>,
Petr Mladek <pmladek@...e.com>,
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, 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 :-)
Powered by blists - more mailing lists