From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: byungchul.park@lge.com
Cc: mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] sched: modify how to compute a slice and check a preemptability
Date: Sun, 19 Jul 2015 13:57:14 +0200 [thread overview]
Message-ID: <1437307034.3520.108.camel@gmail.com> (raw)
In-Reply-To: <1437297060-25378-1-git-send-email-byungchul.park@lge.com>
On Sun, 2015-07-19 at 18:11 +0900, byungchul.park@lge.com wrote:
> @@ -3226,6 +3226,12 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
> struct sched_entity *se;
> s64 delta;
>
> + /*
> + * Ensure that a task executes at least for sysctl_sched_min_granularity
> + */
> + if (delta_exec < sysctl_sched_min_granularity)
> + return;
> +
Think about what this does to a low weight task, or any task in a low
weight group. The scheduler equalizes runtimes for a living, there is
no free lunch. Any runtime larger than fair share that you graciously
grant to random task foo doesn't magically appear out of the vacuum, it
comes out of task foo's wallet. If you drag that hard coded minimum down
into the depths of group scheduling, yeah, every task will get a nice
juicy slice of CPU.. eventually, though you may not live to see it.
(yeah, overrun can and will happen at all depths due to tick
granularity, but you guaranteed it, so I inflated severity a bit;)
> ideal_runtime = sched_slice(cfs_rq, curr);
> delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
> if (delta_exec > ideal_runtime) {
> @@ -3243,9 +3249,6 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
> * narrow margin doesn't have to wait for a full slice.
> * This also mitigates buddy induced latencies under load.
> */
> - if (delta_exec < sysctl_sched_min_granularity)
> - return;
> -
That was about something entirely different. Feel free to remove it
after verifying that it has outlived it's original purpose, but please
don't just move it about at random.
-Mike
next prev parent reply other threads:[~2015-07-19 11:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-19 9:11 [PATCH v3] sched: modify how to compute a slice and check a preemptability byungchul.park
2015-07-19 11:15 ` Peter Zijlstra
2015-07-20 0:08 ` Byungchul Park
2015-07-19 11:57 ` Mike Galbraith [this message]
2015-07-20 0:34 ` Byungchul Park
2015-07-20 3:42 ` Mike Galbraith
2015-07-20 4:47 ` Byungchul Park
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=1437307034.3520.108.camel@gmail.com \
--to=umgwanakikbuti@gmail.com \
--cc=byungchul.park@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.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.