All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: Tejun Heo <tj@kernel.org>
Cc: torvalds@linux-foundation.org, mingo@redhat.com,
	peterz@infradead.org, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH 3/3] sched, sched_ext: Move some declarations from kernel/sched/ext.h to sched.h
Date: Sun, 23 Jun 2024 02:48:42 -0500	[thread overview]
Message-ID: <20240623074842.GD6519@maniforge> (raw)
In-Reply-To: <20240623015057.3383223-4-tj@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Sat, Jun 22, 2024 at 03:50:22PM -1000, Tejun Heo wrote:

Hello Tejun,

> While sched_ext was out of tree, everything sched_ext specific which can be
> put in kernel/sched/ext.h was put there to ease forward porting. However,
> kernel/sched/sched.h is the better location for some of them. Relocate.
> 
> - struct sched_enq_and_set_ctx, sched_deq_and_put_task() and
>   sched_enq_and_set_task().
> 
> - scx_enabled() and scx_switched_all().
> 
> - for_active_class_range() and for_each_active_class(). sched_class
>   declarations are moved above the class iterators for this.
> 
> No functional changes intended.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: David Vernet <void@manifault.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---

[...]

Bringing everything above this into sched.h seems reasonable. See below for
some thoughts about sched_deq_and_put_task() and sched_enq_and_set_task().

>  
>  static inline bool sched_stop_runnable(struct rq *rq)
>  {
> @@ -3698,6 +3733,24 @@ static inline void balance_callbacks(struct rq *rq, struct balance_callback *hea
>  
>  #endif
>  
> +#ifdef CONFIG_SCHED_CLASS_EXT
> +/*
> + * Used by SCX in the enable/disable paths to move tasks between sched_classes
> + * and establish invariants.
> + */
> +struct sched_enq_and_set_ctx {
> +	struct task_struct	*p;
> +	int			queue_flags;
> +	bool			queued;
> +	bool			running;
> +};
> +
> +void sched_deq_and_put_task(struct task_struct *p, int queue_flags,
> +			    struct sched_enq_and_set_ctx *ctx);
> +void sched_enq_and_set_task(struct sched_enq_and_set_ctx *ctx);

I'm not opposed to bringing these into sched.h, but they're implementing a
pattern that's used almost verbatim in a few other places in core.c, so it
would be nice if we could figure out some way to just have every caller use the
same API for doing the whole dequeue/save -> update state -> re-enqueue/restore
dance. We had SCHED_CHANGE_BLOCK [0] way back in v2, but IIRC we dropped it
because upstream was moving towards a more generic implementation. It looks
like that hasn't materialized yet, so maybe we should resurrect that?

[0]: https://lore.kernel.org/all/20230128001639.3510083-3-tj@kernel.org/

Anyways, no objection from me in moving this into sched.h (as long as Peter,
Thomas and Ingo are OK with it). But it does feel kind of unfortunate to stick
it there in its current form given that it's only used by ext.c, despite being
95% of the way there for quite a few potential callsites in core.c.

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-06-23  7:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-23  1:50 [PATCHSET sched_ext/for-6.11] sched_ext: Clean up kernel/sched/ext.h Tejun Heo
2024-06-23  1:50 ` [PATCH 1/3] sched_ext: Minor cleanups in kernel/sched/ext.h Tejun Heo
2024-06-23  7:16   ` David Vernet
2024-06-23  1:50 ` [PATCH 2/3] sched, sched_ext: Open code for_balance_class_range() Tejun Heo
2024-06-23  7:17   ` David Vernet
2024-06-23  1:50 ` [PATCH 3/3] sched, sched_ext: Move some declarations from kernel/sched/ext.h to sched.h Tejun Heo
2024-06-23  7:48   ` David Vernet [this message]
2024-07-08 19:39 ` [PATCHSET sched_ext/for-6.11] sched_ext: Clean up kernel/sched/ext.h Tejun Heo

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=20240623074842.GD6519@maniforge \
    --to=void@manifault.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.