Hi,
On Tue, 11 Sep 2007, Mike Galbraith wrote:
> I still see the fairtest2 sleeper startup anomaly. Sometimes it starts
> up normally, others the sleeper is a delayed. Seems to require idle
> time to trigger worst case startup delay.
>
> 14854 root 20 0 1568 468 384 R 52 0.0 0:0
On Tue, 2007-09-11 at 01:23 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 8 Sep 2007, Mike Galbraith wrote:
>
> > > On Sun, 2 Sep 2007, Ingo Molnar wrote:
> > >
> > > Below is a patch updated against the latest git tree, no major changes.
> >
> > Interesting, I see major behavioral changes.
> >
Hi,
On Sat, 8 Sep 2007, Mike Galbraith wrote:
> > On Sun, 2 Sep 2007, Ingo Molnar wrote:
> >
> > Below is a patch updated against the latest git tree, no major changes.
>
> Interesting, I see major behavioral changes.
>
> I still see an aberration with fairtest2. On startup, the hog component
On Sat, 2007-09-08 at 09:56 +0200, Mike Galbraith wrote:
>
They weren't all repeats after all, the last few were...
[ 120.267389] 2,f73035a0(5624): 1fa7e90b58c,1fb3b46,f73035a0(5624),5
[ 120.281110] WARNING: at kernel/sched_norm.c:413 entity_tick()
[ 120.294101] [] show_trace_log_lvl+0x
On Fri, 2007-09-07 at 17:35 +0200, Roman Zippel wrote:
> Hi,
>
> On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> Below is a patch updated against the latest git tree, no major changes.
Interesting, I see major behavioral changes.
I still see an aberration with fairtest2. On startup, the hog compone
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
Below is a patch updated against the latest git tree, no major changes.
For a split version I'm still waiting for some more explanation about the
CFS tuning parameter.
I added another check for the debug version so that any inbalances (as
e.g. Mike se
Am Montag, den 03.09.2007, 04:58 +0200 schrieb Roman Zippel:
> Hi,
>
> On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> > > Did you even try to understand what I wrote? I didn't say that it's a
> > > "common problem", it's a conceptual problem. The rounding has been
> > > improved lately, so it's not
On Mon, 2007-09-03 at 20:20 +0200, Roman Zippel wrote:
> Basically that's it and I hope that explains the basic math a bit easier. :-)
>
It helps a tiny bit .. However, I appreciate that you took the time to
write this .. Thanks you.
Daniel
-
To unsubscribe from this list: send the line "unsubs
Hi,
On Sun, 2 Sep 2007, Daniel Walker wrote:
> For instance if there are three tasks in the system. Call them A,B, and
> C.
>
> then
>
> time equals "time of A" + "time of B" + "time of C"
Ok, let's take a simple example. :)
If we have three task A, B, C, each with a weight of 1, 2, 3, so th
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> > Did you even try to understand what I wrote? I didn't say that it's a
> > "common problem", it's a conceptual problem. The rounding has been
> > improved lately, so it's not as easy to trigger with some simple busy
> > loops.
>
> As i mentioned i
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > > > so unmodified CFS is 4.6% faster on this box than with Roman's
> > > > patch and it's also more consistent/stable (10 times lower
> > > > fluctuations).
> > >
> > > Was SCHED_DEBUG enabled or disabled for these runs?
> >
> > debugging disabled
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> so i thought you must be aware of the problem - at least considering how
> much you've criticised CFS's "complexity" both in your initial review of
> CFS (which included object size comparisons) and in this patch
> submission of yours (which did not
Hi,
On Sat, 1 Sep 2007, Bill Davidsen wrote:
> > I'd expect Ingo to know better, but the more he refuses to answer my
> > questions, the more I doubt it, at least than it comes to the math part.
> >
> The "math part" is important if you're doing a thesis defense, but
> demonstrating better behav
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > And if you look at the resulting code size/complexity, it actually
> > increases with Roman's patch (UP, nodebug, x86):
> >
> > textdata bss dec hex filename
> > 13420 2281204 148523a04 sched.o.rc5
> > 1355
Hi,
On Sun, 2 Sep 2007, Ingo Molnar wrote:
> And if you look at the resulting code size/complexity, it actually
> increases with Roman's patch (UP, nodebug, x86):
>
> textdata bss dec hex filename
> 13420 2281204 148523a04 sched.o.rc5
> 13554 228
On Sun, 2007-09-02 at 16:47 +0200, Roman Zippel wrote:
> > > (1) time = sum_{t}^{T}(time_{t})
> > > (2) weight_sum = sum_{t}^{T}(weight_{t})
> >
> > I read your description, but I was distracted by this latex style
> > notation .. Could you walk through in english what these two equat
Hi,
On Sat, 1 Sep 2007, Daniel Walker wrote:
> Out of curiosity I was reviewing your patch .. Since you create
> kernel/sched_norm.c as a copy of kernel/sched_fair.c it was hard to see
> what had changed .. So I re-diffed your patch to eliminate
> kernel/sched_norm.c and just make the changes to
* Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On Sun, 2 Sep 2007, Ingo Molnar wrote:
> >
> > Although it _should_ have been a net code size win, because if you
> > look at the diff you'll see that other useful things were removed as
> > well: sleeper fairness, CPU time distribution smarts, tuni
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> > with Peter's queue there are no underflows/overflows either anymore
> > in any synthetic corner-case we could come up with. Peter's queue
> > works well but it's 2.6.24 material.
>
> Did you even try to understand what I wrote? I didn't say that it
On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> Although it _should_ have been a net code size win, because if you look
> at the diff you'll see that other useful things were removed as well:
> sleeper fairness, CPU time distribution smarts, tunings, scheduler
> instrumentation code, etc.
To be f
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> The the patch is near the end of this email.. The most notable thing
> about the rediff is the line count,
>
> 4 files changed, 323 insertions(+), 729 deletions(-)
>
> That's impressive (assuming my rediff is correct). [...]
Yeah, at first glance
Roman Zippel wrote:
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
Maybe I should explain for everyone else (especially after seeing some of
the comments on kerneltrap), why I reacted somewhat irritated on what
looks like such an innocent mail.
The problem is without the necessary background one
On Fri, 2007-08-31 at 04:05 +0200, Roman Zippel wrote:
> Hi,
>
> I'm glad to announce a working prototype of the basic algorithm I
> already suggested last time.
> As I already tried to explain previously CFS has a considerable
> algorithmic and computational complexity. This patch should now make
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
Maybe I should explain for everyone else (especially after seeing some of
the comments on kerneltrap), why I reacted somewhat irritated on what
looks like such an innocent mail.
The problem is without the necessary background one can't know how wrong
On Fri, 2007-08-31 at 15:22 +0200, Roman Zippel wrote:
> Were there some kernel messages while running it?
Nope.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/m
On Fri, 2007-08-31 at 15:22 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 31 Aug 2007, Mike Galbraith wrote:
>
> > I plunked it into 2.6.23-rc4 to see how it reacts to various sleeper
> > loads, and hit some starvation. If I got it in right (think so) there's
> > a bug lurking somewhere. taskset
Hi,
On Fri, 31 Aug 2007, Mike Galbraith wrote:
> I plunked it into 2.6.23-rc4 to see how it reacts to various sleeper
> loads, and hit some starvation. If I got it in right (think so) there's
> a bug lurking somewhere. taskset -c 1 fairtest2 resulted in the below.
> It starts up running both ta
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
> So the most intrusive (math) aspects of your patch have been implemented
> already for CFS (almost a month ago), in a finegrained way.
Interesting claim, please substantiate.
> Peter's patches change the CFS calculations gradually over from
> 'norm
* Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm glad to announce a working prototype of the basic algorithm I
> already suggested last time. As I already tried to explain previously
> CFS has a considerable algorithmic and computational complexity. [...]
hey, thanks for working on thi
On Fri, 2007-08-31 at 04:05 +0200, Roman Zippel wrote:
> Hi,
Greetings,
> I'm glad to announce a working prototype of the basic algorithm I
> already suggested last time.
(finding it difficult to resist the urge to go shopping, I
fast-forwarded to test drive... grep shopping arch/i386/kernel/tcs
30 matches
Mail list logo
