public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: peterz@infradead.org
To: mingo@kernel.org
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	vincent.guittot@linaro.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	corbet@lwn.net, qyousef@layalina.io, chris.hyser@oracle.com,
	patrick.bellasi@matbug.net, pjt@google.com, pavel@ucw.cz,
	qperret@google.com, tim.c.chen@linux.intel.com,
	joshdon@google.com, timj@gnu.org, kprateek.nayak@amd.com,
	yu.c.chen@intel.com, youssefesmat@chromium.org,
	joel@joelfernandes.org, efault@gmx.de, tglx@linutronix.de,
	daniel.m.jordan@oracle.com
Subject: [PATCH 0/2] sched/eevdf: sched_attr::sched_runtime slice hint
Date: Fri, 15 Sep 2023 14:43:54 +0200	[thread overview]
Message-ID: <20230915124354.416936110@noisy.programming.kicks-ass.net> (raw)

Hi,

As promised a while ago, here is a new version of the variable slice length
hint stuff.  Back when I asked for comments on the latency-nice vs slice length
thing, there was very limited feedback on-list, a number of people have
expressed interrest in the slice length hint.


I'm still working on improving the wakeup latency -- but esp. after commit:

  63304558ba5d ("sched/eevdf: Curb wakeup-preemption")

it needs a little more work. Everything I tried so far made it worse.

As is it behaves ok-ish:

  root@ivb-ep:~/bench# cat doit-latency-slice.sh
  #!/bin/bash

  perf bench sched messaging -g 40 -l 12000 &

  sleep 1
  chrt3 -o --sched-runtime $((`cat /debug/sched/base_slice_ns`*10)) 0 cyclictest --policy other -D 5 -q   -H 20000 --histfile data.txt ; grep Latencies data.txt
  chrt3 -o --sched-runtime 0 0 cyclictest --policy other -D 5 -q   -H 20000 --histfile data.txt ; grep Latencies data.txt
  chrt3 -o --sched-runtime $((`cat /debug/sched/base_slice_ns`/10)) 0 cyclictest --policy other -D 5 -q   -H 20000 --histfile data.txt ; grep Latencies data.txt

  wait $!
  root@ivb-ep:~/bench# ./doit-latency-slice.sh
  # Running 'sched/messaging' benchmark:
  # /dev/cpu_dma_latency set to 0us
  # Min Latencies: 00060
  # Avg Latencies: 00990
  # Max Latencies: 224925
  # /dev/cpu_dma_latency set to 0us
  # Min Latencies: 00020
  # Avg Latencies: 00656
  # Max Latencies: 37595
  # /dev/cpu_dma_latency set to 0us
  # Min Latencies: 00016
  # Avg Latencies: 00354
  # Max Latencies: 16687
  # 20 sender and receiver processes per group
  # 40 groups == 1600 processes run

       Total time: 38.246 [sec]


(chrt3 is a hacked up version of util-linux/chrt that allows --sched-runtime unconditionally)


             reply	other threads:[~2023-09-15 12:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15 12:43 peterz [this message]
2023-09-15 12:43 ` [PATCH 1/2] sched/eevdf: Also update slice on placement peterz
2023-10-03 10:42   ` [tip: sched/urgent] " tip-bot2 for Peter Zijlstra
2023-09-15 12:43 ` [PATCH 2/2] sched/eevdf: Use sched_attr::sched_runtime to set request/slice suggestion peterz
2023-09-19  7:53   ` Mike Galbraith
2023-09-24  9:21     ` Mike Galbraith
2023-09-19 22:07   ` Qais Yousef
2023-09-19 22:37     ` Peter Zijlstra
2023-09-20  0:45       ` Qais Yousef
2023-12-10 22:47       ` Qais Yousef
2023-09-16 21:33 ` [PATCH 0/2] sched/eevdf: sched_attr::sched_runtime slice hint Qais Yousef
2023-09-18  3:43   ` Mike Galbraith
2023-09-19 21:08     ` Qais Yousef
2023-09-20  4:02       ` Mike Galbraith

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=20230915124354.416936110@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=chris.hyser@oracle.com \
    --cc=corbet@lwn.net \
    --cc=daniel.m.jordan@oracle.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=efault@gmx.de \
    --cc=joel@joelfernandes.org \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=patrick.bellasi@matbug.net \
    --cc=pavel@ucw.cz \
    --cc=pjt@google.com \
    --cc=qperret@google.com \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=timj@gnu.org \
    --cc=vincent.guittot@linaro.org \
    --cc=youssefesmat@chromium.org \
    --cc=yu.c.chen@intel.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