Ok I have gained a bit more information on this now. Apparently, the
filter is there, for HPC loads to exclude scheduler activity itself from
the scheduler?
Filtering all the processes for this, seems completely unessecary though.
Depending on what resolution these filters run at, you have
Hello, Uwaysi,
Uwaysi Bin Kareem paradoxuncreated.com> writes:
>
> Ok at 100hz, granularity seems to work as expected. Actually 1000hz for
> desktop seems to be a myth. I have less jitter with 100hz. Very nice. I
> think jitter is 99.99% eliminated from doom 3 now.
>
> Peace Be With You!
>
Ok at 100hz, granularity seems to work as expected. Actually 1000hz for
desktop seems to be a myth. I have less jitter with 100hz. Very nice. I
think jitter is 99.99% eliminated from doom 3 now.
Peace Be With You!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
The 10 ms averager is not the only strange thing. Obviously there are some
good things in this scheduler, since it performs quite well. But I am not
criticising the good.
But the documentation makes a distinction between desktop and server with
the "resolution" parameter.
I tried some value
On Tue, 02 Oct 2012 13:22:53 +0200, Mike Galbraith wrote:
On Tue, 2012-10-02 at 10:07 +0200, Uwaysi Bin Kareem wrote:
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith
wrote:
> On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
>
>> What you can do for the time being is just set
On Tue, 02 Oct 2012 11:19:15 +0200, Mike Galbraith wrote:
On Tue, 2012-10-02 at 08:56 +0200, Uwaysi Bin Kareem wrote:
What you can do for the time being is just set it to 1nS. If that
doesn`t
negatively impact anything, then you know it is bogus.
I already know that there is negative impa
This is just too much code for me to do a quick patch on. It really needs
to be evaulated with concerns to what an optimal scheduler is. That would
be to operate on actual system load ofcourse, not a filtered system load
that doesn`t represent what is actually happening on a computer.
What
Ok, so you don`t know. Well, then it looks like what I said, to me. What
is a 100us load, that gets filtered by a 10ms filter? Nothing.
Or a very very small value that rises and falls over 10ms.
Load-distribution based on a spike that happened a long time ago (in
computing terms) seems very o
On Mon, 01 Oct 2012 06:06:37 +0200, Mike Galbraith wrote:
On Sun, 2012-09-30 at 13:44 +0200, Uwaysi Bin Kareem wrote:
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t that counterintuitive
Just to illustrate, you have a filter that lasts 10ms, and a cpu process
that lasts 100uS
Original spike
5 |
4 |
3 |
2 |
1 |
0 |
0ms___10ms
Filtered spike
5
4
3
2
1 .
0.. ..
0ms10ms
Not only is the filtere
I also did a quick hack changing some of those values, giving
non-interrputed audiostream with audioapp alone, at 0.7ms. (on a core2duo
@ 2.5ghz)
That is actually better than BFS.
Peace Be With You.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Hiya. I just had an initial look at fair.c
There seems to be a 10ms averager in there?
You are aware that that means you work on delayed values?
Isn`t that counterintuitive to the principle of sharing?
That means short bursts of cpu-use will be filtered out, and given less
cpu time.
Starting
12 matches
Mail list logo
