From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Mike Galbraith <efault@gmx.de>,
Paul Turner <pjt@google.com>, Alex Shi <alex.shi@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH 4/5] sched: don't consider upper se in sched_slice()
Date: Thu, 04 Apr 2013 12:18:32 +0530 [thread overview]
Message-ID: <515D2240.9060501@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130404004231.GA10683@lge.com>
Hi Joonsoo,
On 04/04/2013 06:12 AM, Joonsoo Kim wrote:
> Hello, Preeti.
>
> So, how about extending a sched_period with rq->nr_running, instead of
> cfs_rq->nr_running? It is my quick thought and I think that we can ensure
> to run atleast once in this extending sched_period.
Yeah this seems to be correct.This would ensure sched_min_granularity
also. So then in the scenarion where there are 2 tgs in a runqueue with
10 tasks each,when we calculate the sched_slice of any task,the
__sched_period() would return 4*20 = 80ms.
The sched_slice of each of the task would be 80/20 = 4ms. But what about
the sched_slice of each task group? How would that be calculated then?
Let us take the above example and walk through this problem.This would
probably help us spot the issues involved with this.
> And, do we leave a problem if we cannot guaranteed atleast once property?
This would depend on the results of the benchmarks with the changes.I am
unable to comment on this off the top of my head.
Thank you
Regards
Preeti U Murthy
next prev parent reply other threads:[~2013-04-04 6:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 7:58 [PATCH 0/5] optimization, clean-up, correctness about fair.c Joonsoo Kim
2013-03-28 7:58 ` [PATCH 1/5] sched: remove one division operation in find_buiest_queue() Joonsoo Kim
2013-03-28 7:58 ` [PATCH 2/5] sched: factor out code to should_we_balance() Joonsoo Kim
2013-03-29 11:45 ` Peter Zijlstra
2013-04-01 5:10 ` Joonsoo Kim
2013-03-29 11:58 ` Peter Zijlstra
2013-04-01 5:16 ` Joonsoo Kim
2013-04-02 8:10 ` Peter Zijlstra
2013-04-02 9:50 ` Joonsoo Kim
2013-04-02 10:00 ` Peter Zijlstra
2013-04-02 10:29 ` Peter Zijlstra
2013-04-04 0:55 ` Joonsoo Kim
2013-03-28 7:58 ` [PATCH 3/5] sched: clean-up struct sd_lb_stat Joonsoo Kim
2013-03-28 7:58 ` [PATCH 4/5] sched: don't consider upper se in sched_slice() Joonsoo Kim
2013-03-29 7:12 ` Preeti U Murthy
2013-04-01 4:08 ` Joonsoo Kim
2013-04-01 7:06 ` Preeti U Murthy
2013-04-02 2:25 ` Joonsoo Kim
2013-04-02 2:35 ` Mike Galbraith
2013-04-02 9:35 ` Joonsoo Kim
2013-04-02 4:55 ` Preeti U Murthy
2013-04-02 9:26 ` Joonsoo Kim
2013-04-02 17:32 ` Preeti U Murthy
2013-04-04 0:42 ` Joonsoo Kim
2013-04-04 6:48 ` Preeti U Murthy [this message]
2013-04-05 2:06 ` Joonsoo Kim
2013-03-28 7:58 ` [PATCH 5/5] sched: limit sched_slice if it is more than sysctl_sched_latency Joonsoo Kim
2013-03-29 11:35 ` Preeti U Murthy
2013-04-01 5:09 ` Joonsoo Kim
2013-04-01 6:45 ` Preeti U Murthy
2013-04-02 2:02 ` Joonsoo Kim
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=515D2240.9060501@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=alex.shi@intel.com \
--cc=efault@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).