mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Abel Wu <wuyun.abel@bytedance.com>
Cc: Madadi Vineeth Reddy <vineethr@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	 Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	 Valentin Schneider <vschneid@redhat.com>,
	Josh Don <joshdon@google.com>,
	 Tianchen Ding <dtcccc@linux.alibaba.com>,
	 "open list:SCHEDULER" <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH 2/2] sched/fair: Fix premature check of WAKEUP_PREEMPTION
Date: Mon, 24 Feb 2025 14:22:38 +0100	[thread overview]
Message-ID: <CAKfTPtD3YHEoGNB2_41_eeHHgrMBca8FHVhRmMuyrSCXqfthUg@mail.gmail.com> (raw)
In-Reply-To: <9d9d7432-9a5d-4216-ac53-a0f333a35d8f@bytedance.com>

On Sun, 23 Feb 2025 at 09:45, Abel Wu <wuyun.abel@bytedance.com> wrote:
>
> Hi Madadi,
>
> On 2/23/25 2:16 AM, Madadi Vineeth Reddy Wrote:
> > On 21/02/25 21:27, Abel Wu wrote:
> >> On 2/21/25 7:49 PM, Vincent Guittot Wrote:
> >>> On Fri, 21 Feb 2025 at 12:12, Abel Wu <wuyun.abel@bytedance.com> wrote:
> >>>>
> >>>> Idle tasks are by definition preempted by non-idle tasks whether feat
> >>>> WAKEUP_PREEMPTION is enabled or not. This isn't true any longer since
> >>>
> >>> I don't think it's true, only "sched_idle never preempts others" is
> >>> always true but sched_feat(WAKEUP_PREEMPTION) is mainly there for
> >>> debug purpose so if WAKEUP_PREEMPTION is false then nobody preempts
> >>> others at wakeup, idle, batch or normal
> >>
> >> Hi Vincent, thanks for your comment!
> >>
> >> The SCHED_IDLE "definition" of being preempted by non-idle tasks comes
> >> from commit 6bc912b71b6f ("sched: SCHED_OTHER vs SCHED_IDLE isolation")
> >> which said:
> >>
> >>      - no SCHED_IDLE buddies
> >>      - never let SCHED_IDLE preempt on wakeup
> >>      - always preempt SCHED_IDLE on wakeup
> >>      - limit SLEEPER fairness for SCHED_IDLE
> >>
> >> and that commit let it be preempted before checking WAKEUP_PREEMPTION.
> >> The rules were introduced in 2009, and to the best of my knowledge there
> >> seemed no behavior change ever since. Please correct me if I missed
> >> anything.
> >
> > As Vincent mentioned, WAKEUP_PREEMPTION is primarily for debugging. Maybe
> > it would help to document that SCHED_IDLE tasks are not preempted by non-idle
> > tasks when WAKEUP_PREEMPTION is disabled. Otherwise, the intent of having no
> > preemptions for debugging would be lost.
> >
> > Thoughts?
>
> I am not sure I really understand the purpose of this debug feature.

I'm not sure that it has been even be used or useful for the last
couple of years. Should we just remove it ?

> If it wants to provide a way to check whether a performance degrade of
> certain workload is due to overscheduling or not, then do we really
> care about performance of SCHED_IDLE workloads and why?
>
> IMHO preempting SCHED_IDLE before WAKEUP_PREEMPTION is to preserve the
> IDLE semantics trying to behave like real idle task. It is somehow
> weird to me that we treat sched-idle cpus as idle while don't let the
> non-idle tasks run immediately on sched-idle cpus on debug case.
>
> Thanks,
>         Abel
>

      parent reply	other threads:[~2025-02-24 13:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-21 11:12 [PATCH 0/2] Fix SCHED_IDLE behavior on wakeup preemption Abel Wu
2025-02-21 11:12 ` [PATCH 1/2] sched/fair: Do not let idle entities preempt others Abel Wu
2025-02-21 11:48   ` Vincent Guittot
2025-02-21 19:54   ` Josh Don
2025-02-22 17:12   ` Madadi Vineeth Reddy
2025-02-22 17:48   ` Madadi Vineeth Reddy
2025-02-23  8:45     ` Abel Wu
2025-02-21 11:12 ` [PATCH 2/2] sched/fair: Fix premature check of WAKEUP_PREEMPTION Abel Wu
2025-02-21 11:49   ` Vincent Guittot
2025-02-21 15:57     ` Abel Wu
2025-02-22 18:16       ` Madadi Vineeth Reddy
2025-02-23  8:44         ` Abel Wu
2025-02-23 10:25           ` Madadi Vineeth Reddy
2025-02-23 11:22             ` Abel Wu
2025-02-24 13:47               ` Vincent Guittot
2025-02-24 14:10                 ` Phil Auld
2025-02-25 17:14                   ` Vincent Guittot
2025-02-25  6:29                 ` Abel Wu
2025-02-25 17:15                   ` Vincent Guittot
2025-02-26  7:34                     ` Abel Wu
2025-02-25  6:56                 ` Tianchen Ding
2025-02-24 13:22           ` Vincent Guittot [this message]

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=CAKfTPtD3YHEoGNB2_41_eeHHgrMBca8FHVhRmMuyrSCXqfthUg@mail.gmail.com \
    --to=vincent.guittot@linaro.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=dtcccc@linux.alibaba.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vineethr@linux.ibm.com \
    --cc=vschneid@redhat.com \
    --cc=wuyun.abel@bytedance.com \
    /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

all inboxes | Powered by JetHome®