public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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