[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230809202440.012625269@infradead.org>
Date: Wed, 09 Aug 2023 22:24:40 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: mingo@...hat.com
Cc: peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, vschneid@...hat.com,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/8] sched: Use lock guards, wave 2
Hi, as promised, here is the second part of the SBRM patches.
Now that we're a little used to them, these are a little more involved.
New in this series, over the guard()() and scoped_guard () usage, is CLASS().
CLASS() is very like guard() except it also takes a name argument. So where
guard() instantiates an 'anonymous' variable, CLASS() instantiates an
explicitly named one.
CLASS(task_rq_lock, rq_guard)(p);
which can be read like:
class_task_rq_lock_t rq_guard __cleanup(class_task_rq_lock_destructor) =
class_task_rq_lock_constructor(p);
[[ Notable: guard(name) := CLASS(name, __UNIQUE_ID(guard)) ]]
The advantage in this specific case is that the guard object of task_rq_lock
will contain the 'struct rq *' which we'll need.
Another use of CLASS() is:
CLASS(find_get_task, p)(pid);
Where 'p' is of 'struct task_struct *' type and the constructor does the
pid->task_struct lookup and the destructor does put_task_struct.
Again, mostly aimed at getting rid of error gotos. The final patch is a bunch
of random conversions that happened while I was poking around and playing with
things.
Also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/guards2
Next in line is kernel/events/core.c, but I might not bore all of you with those
patches :-)
Powered by blists - more mailing lists