From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>, Balazs Scheidler <bazsi@balabit.hu>,
linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [patch] Re: scheduler oddity [bug?]
Date: Mon, 09 Mar 2009 14:27:47 +0100 [thread overview]
Message-ID: <1236605267.8389.490.camel@laptop> (raw)
In-Reply-To: <1236604563.6027.8.camel@marge.simson.net>
On Mon, 2009-03-09 at 14:16 +0100, Mike Galbraith wrote:
> On Mon, 2009-03-09 at 12:04 +0100, Peter Zijlstra wrote:
>
> > OK, talked a bit with Ingo, the reason you're doing is that avg_overlap
> > can easily grow stale.. I can see that happen indeed.
> >
> > So the 'perfect' thing would be a task-runtime decay, barring that the
> > preemption thing seems a sane enough hart-beat of a task.
> >
> > How does the below look to you?
>
> Other than the fact that the test for sync reject is currently
> avg_overlap > sysctl_sched_migration_cost, looks fine to me. Having it
> capped at the boundary is probably the better way to go.
Ah, yes, and looking at update_avg() we'll also discard the lower 3
bits, so we'll never actually reach.
So I guess it should read something like:
update_avg(&prev->se.avg_overlap, 2*sysctl_sched_migration_cost);
or somesuch.
Does it actually solve the reported problem? I've only thought about the
issue so far :-)
next prev parent reply other threads:[~2009-03-09 13:29 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-07 17:47 scheduler oddity [bug?] Balazs Scheidler
2009-03-07 18:47 ` Balazs Scheidler
2009-03-08 19:45 ` Balazs Scheidler
2009-03-08 22:03 ` Willy Tarreau
2009-03-09 3:35 ` Mike Galbraith
2009-03-09 11:19 ` David Newall
2009-03-08 9:42 ` Mike Galbraith
2009-03-08 9:58 ` Mike Galbraith
2009-03-08 10:02 ` Mike Galbraith
2009-03-08 10:19 ` Peter Zijlstra
2009-03-08 13:35 ` Mike Galbraith
2009-03-08 15:39 ` Ingo Molnar
2009-03-08 16:20 ` Mike Galbraith
2009-03-08 17:52 ` Ingo Molnar
2009-03-08 18:39 ` Mike Galbraith
2009-03-08 18:55 ` Ingo Molnar
2009-03-09 4:10 ` Mike Galbraith
2009-03-09 6:52 ` Ingo Molnar
2009-03-09 8:02 ` [patch] " Mike Galbraith
2009-03-09 8:07 ` Ingo Molnar
2009-03-09 10:16 ` David Newall
2009-03-09 11:04 ` Peter Zijlstra
2009-03-09 13:16 ` Mike Galbraith
2009-03-09 13:27 ` Peter Zijlstra [this message]
2009-03-09 13:51 ` Mike Galbraith
2009-03-09 14:00 ` David Newall
2009-03-09 14:19 ` Peter Zijlstra
2009-03-10 0:20 ` David Newall
2009-03-09 13:37 ` Mike Galbraith
2009-03-09 13:46 ` Peter Zijlstra
2009-03-09 13:58 ` Mike Galbraith
2009-03-09 14:11 ` Mike Galbraith
2009-03-09 14:41 ` Peter Zijlstra
2009-03-09 15:30 ` Mike Galbraith
2009-03-09 16:12 ` Peter Zijlstra
2009-03-09 17:28 ` Mike Galbraith
2009-03-15 13:53 ` Balazs Scheidler
2009-03-15 17:16 ` Mike Galbraith
2009-03-15 18:57 ` Ingo Molnar
2009-03-16 11:55 ` Balazs Scheidler
2009-03-09 15:57 ` Balazs Scheidler
2009-03-10 3:16 ` Mike Galbraith
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=1236605267.8389.490.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=bazsi@balabit.hu \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=w@1wt.eu \
/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