From: Frederic Weisbecker <frederic@kernel.org>
To: Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/8] timers/migration: Use a single struct for hierarchy walk data
Date: Tue, 2 Jul 2024 13:43:39 +0200 [thread overview]
Message-ID: <ZoPn65jVGSRn2mTI@localhost.localdomain> (raw)
In-Reply-To: <20240701-tmigr-fixes-v3-4-25cd5de318fb@linutronix.de>
Le Mon, Jul 01, 2024 at 12:18:40PM +0200, Anna-Maria Behnsen a écrit :
> Two different structs are defined for propagating data from one to another
> level when walking the hierarchy. Several struct members exist in both
> structs which makes generalization harder.
>
> Merge those two structs into a single one and use it directly in
> walk_groups() and the corresponding function pointers instead of
> introducing pointer casting all over the place.
>
> Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
> ---
> kernel/time/timer_migration.c | 126 ++++++++++++++++++------------------------
> 1 file changed, 55 insertions(+), 71 deletions(-)
>
> diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c
> index 0ae7f2084d27..b4391abfb4a9 100644
> --- a/kernel/time/timer_migration.c
> +++ b/kernel/time/timer_migration.c
> @@ -475,69 +475,31 @@ static bool tmigr_check_lonely(struct tmigr_group *group)
> return bitmap_weight(&active, BIT_CNT) <= 1;
> }
>
> -typedef bool (*up_f)(struct tmigr_group *, struct tmigr_group *, void *);
> -
> -static void __walk_groups(up_f up, void *data,
> - struct tmigr_cpu *tmc)
> -{
> - struct tmigr_group *child = NULL, *group = tmc->tmgroup;
> -
> - do {
> - WARN_ON_ONCE(group->level >= tmigr_hierarchy_levels);
> -
> - if (up(group, child, data))
> - break;
> -
> - child = group;
> - group = group->parent;
> - } while (group);
> -}
> -
> -static void walk_groups(up_f up, void *data, struct tmigr_cpu *tmc)
> -{
> - lockdep_assert_held(&tmc->lock);
> -
> - __walk_groups(up, data, tmc);
> -}
> -
> /**
> * struct tmigr_walk - data required for walking the hierarchy
> * @nextexp: Next CPU event expiry information which is handed into
> * the timer migration code by the timer code
> * (get_next_timer_interrupt())
> - * @firstexp: Contains the first event expiry information when last
> - * active CPU of hierarchy is on the way to idle to make
> - * sure CPU will be back in time. It is updated in top
> - * level group only. Be aware, there could occur a new top
> - * level of the hierarchy between the 'top level call' in
> - * tmigr_update_events() and the check for the parent group
> - * in walk_groups(). Then @firstexp might contain a value
> - * != KTIME_MAX even if it was not the final top
> - * level. This is not a problem, as the worst outcome is a
> - * CPU which might wake up a little early.
> + * @firstexp: Contains the first event expiry information when
> + * hierarchy is completely idle. When CPU itself was the
> + * last going idle, information makes sure, that CPU will
> + * be back in time. When using this value in the remote
> + * expiry case, firstexp is stored in the per CPU tmigr_cpu
> + * struct of CPU which expires remote timers. It is updated
> + * in top level group only. Be aware, there could occur a
> + * new top level of the hierarchy between the 'top level
> + * call' in tmigr_update_events() and the check for the
> + * parent group in walk_groups(). Then @firstexp might
> + * contain a value != KTIME_MAX even if it was not the
> + * final top level. This is not a problem, as the worst
> + * outcome is a CPU which might wake up a little early.
> * @evt: Pointer to tmigr_event which needs to be queued (of idle
> * child group)
> * @childmask: childmask of child group
> * @remote: Is set, when the new timer path is executed in
> * tmigr_handle_remote_cpu()
> - */
> -struct tmigr_walk {
> - u64 nextexp;
> - u64 firstexp;
> - struct tmigr_event *evt;
> - u8 childmask;
> - bool remote;
> -};
> -
> -/**
> - * struct tmigr_remote_data - data required for remote expiry hierarchy walk
> * @basej: timer base in jiffies
> * @now: timer base monotonic
> - * @firstexp: returns expiry of the first timer in the idle timer
> - * migration hierarchy to make sure the timer is handled in
> - * time; it is stored in the per CPU tmigr_cpu struct of
> - * CPU which expires remote timers
> - * @childmask: childmask of child group
> * @check: is set if there is the need to handle remote timers;
> * required in tmigr_requires_handle_remote() only
> * @tmc_active: this flag indicates, whether the CPU which triggers
> @@ -546,15 +508,43 @@ struct tmigr_walk {
> * idle, only the first event of the top level has to be
> * considered.
> */
> -struct tmigr_remote_data {
> - unsigned long basej;
> - u64 now;
> - u64 firstexp;
> - u8 childmask;
> - bool check;
> - bool tmc_active;
> +struct tmigr_walk {
> + u64 nextexp;
> + u64 firstexp;
> + struct tmigr_event *evt;
> + u8 childmask;
> + bool remote;
> + unsigned long basej;
> + u64 now;
> + bool check;
> + bool tmc_active;
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Ideas for a subsequent patch:
Is tmc_active actually useful? It must always be true in
tmigr_requires_handle_remote_up() since that function is only called
on active CPUs.
In fact the following condition is dead code:
/*
* When there is a parent group and the CPU which triggered the
* hierarchy walk is not active, proceed the walk to reach the top level
* group before reading the next_expiry value.
*/
if (group->parent && !data->tmc_active)
goto out;
Thanks.
next prev parent reply other threads:[~2024-07-02 11:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 10:18 [PATCH v3 0/8] timers/migration: Fix three possible races and some improvements Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 1/8] timers/migration: Do not rely always on group->parent Anna-Maria Behnsen
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 2/8] timers/migration: Move hierarchy setup into cpuhotplug prepare callback Anna-Maria Behnsen
2024-07-01 21:49 ` Frederic Weisbecker
2024-07-03 20:28 ` [PATCH v4 " Anna-Maria Behnsen
2024-07-03 21:24 ` Frederic Weisbecker
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-11 8:56 ` [PATCH v4 2/8] " Alexander Stein
2024-07-15 10:39 ` Jon Hunter
2024-07-15 10:44 ` Frederic Weisbecker
2024-07-15 13:25 ` Jon Hunter
2024-07-01 10:18 ` [PATCH v3 3/8] timers/migration: Improve tracing Anna-Maria Behnsen
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 4/8] timers/migration: Use a single struct for hierarchy walk data Anna-Maria Behnsen
2024-07-02 11:43 ` Frederic Weisbecker [this message]
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 5/8] timers/migration: Read childmask and parent pointer in a single place Anna-Maria Behnsen
2024-07-02 12:04 ` Frederic Weisbecker
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-15 19:28 ` [PATCH v3 5/8] " Frederic Weisbecker
2024-07-01 10:18 ` [PATCH v3 6/8] timers/migration: Rename childmask by parentmask to make naming more obvious Anna-Maria Behnsen
2024-07-02 12:45 ` Frederic Weisbecker
2024-07-03 20:31 ` [PATCH v4 6/8] timers/migration: Rename childmask by groupmask " Anna-Maria Behnsen
2024-07-03 21:33 ` Frederic Weisbecker
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 7/8] timers/migration: Spare write when nothing changed Anna-Maria Behnsen
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-01 10:18 ` [PATCH v3 8/8] timers/migration: Fix grammar in comment Anna-Maria Behnsen
2024-07-02 12:51 ` Frederic Weisbecker
2024-07-04 18:32 ` [tip: timers/core] " tip-bot2 for Anna-Maria Behnsen
2024-07-11 15:44 ` [PATCH v3 0/8] timers/migration: Fix three possible races and some improvements Anna-Maria Behnsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZoPn65jVGSRn2mTI@localhost.localdomain \
--to=frederic@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox