All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <yu.c.chen@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Tim Chen <tim.c.chen@intel.com>,
	Mel Gorman <mgorman@techsingularity.net>
Cc: Juri Lelli <juri.lelli@redhat.com>,
	Rik van Riel <riel@surriel.com>, Aaron Lu <aaron.lu@intel.com>,
	Abel Wu <wuyun.abel@bytedance.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Yicong Yang <yangyicong@hisilicon.com>,
	"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
	Ingo Molnar <mingo@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>,
	Hillf Danton <hdanton@sina.com>,
	Honglei Wang <wanghonglei@didichuxing.com>,
	Len Brown <len.brown@intel.com>, Chen Yu <yu.chen.surf@gmail.com>,
	linux-kernel@vger.kernel.org, Chen Yu <yu.c.chen@intel.com>
Subject: [RFC PATCH v2 0/2] sched/fair: Choose the CPU where short task is running during wake up
Date: Sun, 23 Oct 2022 23:31:50 +0800	[thread overview]
Message-ID: <cover.1666531576.git.yu.c.chen@intel.com> (raw)

At LPC 2022 Real-time and Scheduling Micro Conference we presented
the cross CPU wakeup issue. This patch is a text version of the
talk, and hopefully, we can clarify the problem and appreciate any
feedback.

The main purpose of this change is to avoid too many crosses CPU
wake up when the system is busy. Please refer to the commit log
of [PATCH 2/2] for detail.

This patch set is composed of two parts. The first part is to introduce
the definition of a short-duration task. The second part leverages the
first part to choose a CPU where only one short-duration task is running
on. This CPU is chosen as the candidate to place a woken task.

This version is modified based on the following feedback on v1:
1. Tim suggested raising the bar to choose a CPU with a short-duration
   task, by checking if the short-duration task is the only runnable
   task on the target CPU.
2. To address Peter's concern: would this patch inhibit spreading the
   workload when there are idle CPUs around? The patch would only take
   effect when the system is relatively busy, and only choose the CPU
   where only one short-duration task is running.
3. Prateek, Honglwei and Hillf suggsted to prefer previous idle CPU to the
   CPU with short-duration task running.

v1 link: https://lore.kernel.org/lkml/20220915165407.1776363-1-yu.c.chen@intel.com/

Chen Yu (2):
  sched/fair: Introduce short duration task check
  sched/fair: Choose the CPU where short task is running during wake up

 include/linux/sched.h   |  8 ++++
 kernel/sched/core.c     |  2 +
 kernel/sched/fair.c     | 99 +++++++++++++++++++++++++++++++++++++++++
 kernel/sched/features.h |  1 +
 4 files changed, 110 insertions(+)

-- 
2.25.1


             reply	other threads:[~2022-10-23 15:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-23 15:31 Chen Yu [this message]
2022-10-23 15:32 ` [RFC PATCH v2 1/2] sched/fair: Introduce short duration task check Chen Yu
2022-10-24 10:10   ` Abel Wu
2022-10-25  5:16     ` Chen Yu
2022-11-03 12:44   ` Peter Zijlstra
2022-11-04  4:09     ` Chen Yu
2022-10-23 15:33 ` [RFC PATCH v2 2/2] sched/fair: Choose the CPU where short task is running during wake up Chen Yu
2022-11-02  8:18   ` kernel test robot
2022-11-03 13:04   ` Peter Zijlstra
2022-11-04  4:35     ` Chen Yu
2022-11-22 10:31 ` [RFC PATCH v2 0/2] " K Prateek Nayak
2022-11-30  4:03   ` Chen Yu
2022-12-02  3:21     ` K Prateek Nayak

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=cover.1666531576.git.yu.c.chen@intel.com \
    --to=yu.c.chen@intel.com \
    --cc=aaron.lu@intel.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gautham.shenoy@amd.com \
    --cc=hdanton@sina.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=rostedt@goodmis.org \
    --cc=tim.c.chen@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=wanghonglei@didichuxing.com \
    --cc=wuyun.abel@bytedance.com \
    --cc=yangyicong@hisilicon.com \
    --cc=yu.chen.surf@gmail.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 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.