| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Sep 2007 12:10:44 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Cc: Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Dmitry Adamushko <dmitry.adamushko@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git] CFS-devel, latest code
* Ingo Molnar <mingo@...e.hu> wrote:
>
> * Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com> wrote:
>
> > On Tue, Sep 25, 2007 at 11:13:31AM +0200, Ingo Molnar wrote:
> > > ok, i'm too seeing some sort of latency weirdness with
> > > CONFIG_FAIR_GROUP_SCHED enabled, _if_ there's Xorg involved which runs
> > > under root uid on my box - and hence gets 50% of all CPU time.
> > >
> > > Srivatsa, any ideas? It could either be an accounting buglet (less
> > > likely, seems like the group scheduling bits stick to the 50% splitup
> > > nicely), or a preemption buglet. One potential preemption buglet would
> > > be for the group scheduler to not properly preempt a running task when a
> > > task from another uid is woken?
> >
> > Yep, I noticed that too.
> >
> > check_preempt_wakeup()
> > {
> > ...
> >
> > if (is_same_group(curr, p)) {
> > ^^^^^^^^^^^^^
> >
> > resched_task();
> > }
> >
> > }
> >
> > Will try a fix to check for preemption at higher levels ..
>
> i bet fixing this will increase precision of group scheduling as well.
> Those long latencies can be thought of as noise as well, and the
> fair-scheduling "engine" might not be capable to offset all sources of
> noise. So generally, while we allow a certain amount of lag in
> preemption decisions (wakeup-granularity, etc.), with which the
> fairness engine will cope just fine, we do not want to allow unlimited
> lag.
hm, i tried the naive patch. In theory the vruntime of all scheduling
entities should be 'compatible' and comparable (that's the point behind
using vruntime - the fairness engine drives each vruntime forward and
tries to balance them).
So the patch below just removes the is_same_group() condition. But i can
still see bad (and obvious) latencies with Mike's 2-hogs test:
taskset 01 perl -e 'while (1) {}' &
nice -19 taskset 02 perl -e 'while (1) {}' &
So something's amiss.
Ingo
------------------->
Subject: sched: group scheduler wakeup latency fix
From: Ingo Molnar <mingo@...e.hu>
group scheduler wakeup latency fix.
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/sched_fair.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -785,6 +785,7 @@ static void check_preempt_wakeup(struct
{
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
+ s64 delta;
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -792,12 +793,10 @@ static void check_preempt_wakeup(struct
resched_task(curr);
return;
}
- if (is_same_group(curr, p)) {
- s64 delta = curr->se.vruntime - p->se.vruntime;
+ delta = curr->se.vruntime - p->se.vruntime;
- if (delta > (s64)sysctl_sched_wakeup_granularity)
- resched_task(curr);
- }
+ if (delta > (s64)sysctl_sched_wakeup_granularity)
+ resched_task(curr);
}
static struct task_struct *pick_next_task_fair(struct rq *rq)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists