> regarding the fairness of the different schedulers, please note the
> different runtimes for each component of the workload:
>
> LTMM: 5655.07/ 5682
> LTMB: 7729.81/ 7755
> LTBM: 7720.70/ 7746
>
> this means that a fair scheduler would _not_ be the one that finishes
>
* Michael Gerdau <[EMAIL PROTECTED]> wrote:
> There are 3 scenarios:
> j1 - all 3 tasks run sequentially
>/proc/sys/kernel/sched_granularity_ns=400
>/proc/sys/kernel/rr_interval=16
> j3 - all 3 tasks run in parallel
>
William Lee Irwin III wrote:
> On Thu, May 03, 2007 at 09:42:51AM +0300, Al Boldi wrote:
> > sched_rr_get_interval(0, );
> > printf("pid %d, prio %3d, interval of %d nsec\n", getpid(),
> > getpriority(PRIO_PROCESS, 0), ts.tv_nsec);
>
> Oh dear. What are you trying to figure out
> William Lee Irwin III wrote:
On Thu, May 03, 2007 at 09:42:51AM +0300, Al Boldi wrote:
> sched_rr_get_interval(0, );
> printf("pid %d, prio %3d, interval of %d nsec\n", getpid(),
> getpriority(PRIO_PROCESS, 0), ts.tv_nsec);
Oh dear. What are you trying to figure out from the
William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >> That's odd. The ->load_weight changes should've improved that quite
> >> a bit. There may be something slightly off in how lag is computed,
> >> or maybe the O(n) lag issue Ying Tang spotted is biting you.
>
> On Thu, May 03, 2007 at
William Lee Irwin III wrote:
William Lee Irwin III wrote:
That's odd. The -load_weight changes should've improved that quite
a bit. There may be something slightly off in how lag is computed,
or maybe the O(n) lag issue Ying Tang spotted is biting you.
On Thu, May 03, 2007 at 06:51:43AM
William Lee Irwin III wrote:
On Thu, May 03, 2007 at 09:42:51AM +0300, Al Boldi wrote:
sched_rr_get_interval(0, ts);
printf(pid %d, prio %3d, interval of %d nsec\n, getpid(),
getpriority(PRIO_PROCESS, 0), ts.tv_nsec);
Oh dear. What are you trying to figure out from the task's
William Lee Irwin III wrote:
On Thu, May 03, 2007 at 09:42:51AM +0300, Al Boldi wrote:
sched_rr_get_interval(0, ts);
printf(pid %d, prio %3d, interval of %d nsec\n, getpid(),
getpriority(PRIO_PROCESS, 0), ts.tv_nsec);
Oh dear. What are you trying to figure out from the
* Michael Gerdau [EMAIL PROTECTED] wrote:
There are 3 scenarios:
j1 - all 3 tasks run sequentially
/proc/sys/kernel/sched_granularity_ns=400
/proc/sys/kernel/rr_interval=16
j3 - all 3 tasks run in parallel
/proc/sys/kernel/sched_granularity_ns=400
regarding the fairness of the different schedulers, please note the
different runtimes for each component of the workload:
LTMM: 5655.07/ 5682
LTMB: 7729.81/ 7755
LTBM: 7720.70/ 7746
this means that a fair scheduler would _not_ be the one that finishes
them first
William Lee Irwin III wrote:
>> That's odd. The ->load_weight changes should've improved that quite
>> a bit. There may be something slightly off in how lag is computed,
>> or maybe the O(n) lag issue Ying Tang spotted is biting you.
On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
> Is
William Lee Irwin III wrote:
> Con Kolivas wrote:
> >> Looks good, thanks. Ingo's been hard at work since then and has v8 out
> >> by now. SD has not changed so you wouldn't need to do the whole lot of
> >> tests on SD again unless you don't trust some of the results.
>
> On Thu, May 03, 2007 at
Con Kolivas wrote:
>> Looks good, thanks. Ingo's been hard at work since then and has v8 out by
>> now. SD has not changed so you wouldn't need to do the whole lot of tests
>> on SD again unless you don't trust some of the results.
On Thu, May 03, 2007 at 02:11:39AM +0300, Al Boldi wrote:
> Well,
Con Kolivas wrote:
> On Monday 30 April 2007 18:05, Michael Gerdau wrote:
> > meanwhile I've redone my numbercrunching tests with the following
> > kernels: 2.6.21.1 (mainline)
> > 2.6.21-sd046
> > 2.6.21-cfs-v6
> > running on a dualcore x86_64.
> > [I will run the same test with
On Monday 30 April 2007 18:05, Michael Gerdau wrote:
> i list,
>
> meanwhile I've redone my numbercrunching tests with the following kernels:
> 2.6.21.1 (mainline)
> 2.6.21-sd046
> 2.6.21-cfs-v6
> running on a dualcore x86_64.
> [I will run the same test with 2.6.21.1-cfs-v7 over the
On Monday 30 April 2007 18:05, Michael Gerdau wrote:
i list,
meanwhile I've redone my numbercrunching tests with the following kernels:
2.6.21.1 (mainline)
2.6.21-sd046
2.6.21-cfs-v6
running on a dualcore x86_64.
[I will run the same test with 2.6.21.1-cfs-v7 over the next
Con Kolivas wrote:
On Monday 30 April 2007 18:05, Michael Gerdau wrote:
meanwhile I've redone my numbercrunching tests with the following
kernels: 2.6.21.1 (mainline)
2.6.21-sd046
2.6.21-cfs-v6
running on a dualcore x86_64.
[I will run the same test with 2.6.21.1-cfs-v7 over
Con Kolivas wrote:
Looks good, thanks. Ingo's been hard at work since then and has v8 out by
now. SD has not changed so you wouldn't need to do the whole lot of tests
on SD again unless you don't trust some of the results.
On Thu, May 03, 2007 at 02:11:39AM +0300, Al Boldi wrote:
Well, I
William Lee Irwin III wrote:
Con Kolivas wrote:
Looks good, thanks. Ingo's been hard at work since then and has v8 out
by now. SD has not changed so you wouldn't need to do the whole lot of
tests on SD again unless you don't trust some of the results.
On Thu, May 03, 2007 at 02:11:39AM
William Lee Irwin III wrote:
That's odd. The -load_weight changes should've improved that quite
a bit. There may be something slightly off in how lag is computed,
or maybe the O(n) lag issue Ying Tang spotted is biting you.
On Thu, May 03, 2007 at 06:51:43AM +0300, Al Boldi wrote:
Is it not
i list,
meanwhile I've redone my numbercrunching tests with the following kernels:
2.6.21.1 (mainline)
2.6.21-sd046
2.6.21-cfs-v6
running on a dualcore x86_64.
[I will run the same test with 2.6.21.1-cfs-v7 over the next days,
likely tonight]
The tests consist of 3 tasks (named LTMM,
i list,
meanwhile I've redone my numbercrunching tests with the following kernels:
2.6.21.1 (mainline)
2.6.21-sd046
2.6.21-cfs-v6
running on a dualcore x86_64.
[I will run the same test with 2.6.21.1-cfs-v7 over the next days,
likely tonight]
The tests consist of 3 tasks (named LTMM,
22 matches
Mail list logo
