From: Peter Zijlstra <peterz@infradead.org>
To: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
heiko.carstens@de.ibm.com, linux-s390@vger.kernel.org,
schwidefsky@de.ibm.com
Subject: Re: [RFC] [PATCH 0/3] sched: Support for real CPU runtime and SMT scaling
Date: Sat, 31 Jan 2015 12:43:07 +0100 [thread overview]
Message-ID: <20150131114307.GU2896@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <1422626562-6966-1-git-send-email-phacht@linux.vnet.ibm.com>
On Fri, Jan 30, 2015 at 03:02:39PM +0100, Philipp Hachtmann wrote:
> Hello,
>
> when using "real" processors the scheduler can make its decisions based
> on wall time. But CPUs under hypervisor control are sometimes
> unavailable without further notice to the guest operating system.
> Using wall time for scheduling decisions in this case will lead to
> unfair decisions and erroneous distribution of CPU bandwidth when
> using cgroups.
> On (at least) S390 every CPU has a timer that counts the real execution
> time from IPL. When the hypervisor has sheduled out the CPU, the timer
> is stopped. So it is desirable to use this timer as a source for the
> scheduler's rq runtime calculations.
>
> On SMT systems the consumed runtime of a task might be worth more
> or less depending on the fact that the task can have run alone or not
> during the last delta. This should be scalable based on the current
> CPU utilization.
So we've explicitly never done this before because at the end of the day
its wall time that people using the computer react to.
Also, once you open this door you can have endless discussions of what
constitutes work. People might want to use instructions retired for
instance, to normalize against pipeline stalls.
Also, if your hypervisor starves its vcpus of compute time; how is that
our problem?
Furthermore, we already have some stealtime accounting in
update_rq_clock_task() for the virt crazies^Wpeople.
next prev parent reply other threads:[~2015-01-31 11:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 14:02 [RFC] [PATCH 0/3] sched: Support for real CPU runtime and SMT scaling Philipp Hachtmann
2015-01-30 14:02 ` [PATCH 1/3] sched: Support for CPU runtime and SMT based adaption Philipp Hachtmann
2015-01-30 14:02 ` [PATCH 2/3] s390/cputime: Provide CPU runtime since IPL Philipp Hachtmann
2015-01-30 14:02 ` [PATCH 3/3] s390/cputime: SMT based scaling of CPU runtime deltas Philipp Hachtmann
2015-01-31 11:43 ` Peter Zijlstra [this message]
2015-02-03 14:11 ` [RFC] [PATCH 0/3] sched: Support for real CPU runtime and SMT scaling Martin Schwidefsky
2015-02-05 11:24 ` Peter Zijlstra
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=20150131114307.GU2896@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=phacht@linux.vnet.ibm.com \
--cc=schwidefsky@de.ibm.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