From: David Laight <David.Laight@ACULAB.COM>
To: 'Shrikanth Hegde' <sshegde@linux.vnet.ibm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Swapnil Sapkal <Swapnil.Sapkal@amd.com>,
Aaron Lu <aaron.lu@intel.com>, "x86@kernel.org" <x86@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: RE: [RFC PATCH 1/1] sched: Extend cpu idle state for 1ms
Date: Fri, 4 Aug 2023 14:04:21 +0000 [thread overview]
Message-ID: <f7627afa58294c4480d8f507ee792c2f@AcuMS.aculab.com> (raw)
In-Reply-To: <69076f8e-191b-2e3e-d810-ea72d8ff18bb@linux.vnet.ibm.com>
From: Shrikanth Hegde
> Sent: 26 July 2023 09:05
...
> > + if (sched_clock() < READ_ONCE(rq->idle_end_time) + IDLE_CPU_DELAY_NS)
>
>
> Wouldn't this hurt the latency badly? Specially on a loaded system with
> a workload that does a lot of wakeup.
Having spotted this I'm also rather worried about systems
that are doing (eg) real time audio and need to wakeup a
lot of threads (less than the number of cpu) every (say) 10ms.
It is hard enough waking up a lot of threads quickly without
another 1ms delay being added.
(I'm only talking about 30 threads as well, not 300.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2023-08-04 14:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 19:30 [RFC PATCH 1/1] sched: Extend cpu idle state for 1ms Mathieu Desnoyers
2023-07-26 7:33 ` Shrikanth Hegde
2023-07-26 8:04 ` Shrikanth Hegde
2023-07-26 14:07 ` Mathieu Desnoyers
2023-07-26 17:40 ` Shrikanth Hegde
2023-07-26 18:56 ` Mathieu Desnoyers
2023-07-26 19:16 ` Mathieu Desnoyers
2023-08-01 7:24 ` Aaron Lu
2023-08-01 15:03 ` Chen Yu
2023-08-03 20:21 ` Mathieu Desnoyers
2023-08-03 5:53 ` Swapnil Sapkal
2023-08-03 20:12 ` Mathieu Desnoyers
2023-08-05 15:37 ` Shrikanth Hegde
2023-07-27 5:04 ` Chen Yu
2023-08-01 7:42 ` Aaron Lu
2023-08-04 14:04 ` David Laight [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=f7627afa58294c4480d8f507ee792c2f@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Swapnil.Sapkal@amd.com \
--cc=aaron.lu@intel.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=sshegde@linux.vnet.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=x86@kernel.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.