* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> results:
>
> (SCHED_FIFO)
>
> [EMAIL PROTECTED]:~/storage/prog$ sudo chrt -f 10 ./rr_interval
> time_slice: 0 : 0
>
> (SCHED_RR)
>
> [EMAIL PROTECTED]:~/storage/prog$ sudo chrt 10 ./rr_interval
> time_slice: 0 : 99984800
>
> (SCHED_NORMAL)
>
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
> seems to break GROUP_SCHED. Although, it may be 'oops'-less due to the
> possibility of 'p' being always a valid address.
thanks, applied.
Ingo
-
To unsubscribe from
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
seems to break GROUP_SCHED. Although, it may be 'oops'-less due to the
possibility of 'p' being always a valid address.
thanks, applied.
Ingo
-
To unsubscribe from this
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
results:
(SCHED_FIFO)
[EMAIL PROTECTED]:~/storage/prog$ sudo chrt -f 10 ./rr_interval
time_slice: 0 : 0
(SCHED_RR)
[EMAIL PROTECTED]:~/storage/prog$ sudo chrt 10 ./rr_interval
time_slice: 0 : 99984800
(SCHED_NORMAL)
[EMAIL
On Tue, Oct 02, 2007 at 09:59:04PM +0200, Dmitry Adamushko wrote:
> The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
> seems to break GROUP_SCHED. Although, it may be
> 'oops'-less due to the possibility of 'p' being always a valid
> address.
Thanks for catching it! Patch
The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
seems to break GROUP_SCHED. Although, it may be
'oops'-less due to the possibility of 'p' being always a valid
address.
Signed-off-by: Dmitry Adamushko <[EMAIL PROTECTED]>
---
diff --git a/kernel/sched_fair.c
On 01/10/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
>
> > here is a few patches on top of the recent 'sched-dev':
> >
> > (1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
> > dependent on task's static_prio;
> >
> > (2) [
On 01/10/2007, Ingo Molnar [EMAIL PROTECTED] wrote:
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
here is a few patches on top of the recent 'sched-dev':
(1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
dependent on task's static_prio;
(2) [ cleanup ]
The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
seems to break GROUP_SCHED. Although, it may be
'oops'-less due to the possibility of 'p' being always a valid
address.
Signed-off-by: Dmitry Adamushko [EMAIL PROTECTED]
---
diff --git a/kernel/sched_fair.c
On Tue, Oct 02, 2007 at 09:59:04PM +0200, Dmitry Adamushko wrote:
The following patch (sched: disable sleeper_fairness on SCHED_BATCH)
seems to break GROUP_SCHED. Although, it may be
'oops'-less due to the possibility of 'p' being always a valid
address.
Thanks for catching it! Patch below
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> here is a few patches on top of the recent 'sched-dev':
>
> (1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
> dependent on task's static_prio;
>
> (2) [ cleanup ] calc_weighted() is obsolete, remove it;
>
> (3) [ refactoring
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-09-30 at 21:15 +0200, Dmitry Adamushko wrote:
> >
> > remove obsolete code -- calc_weighted()
> >
>
> Here's another piece of low hanging obsolete fruit.
>
> Remove obsolete TASK_NONINTERACTIVE.
>
> Signed-off-by: Mike Galbraith
On Sun, 2007-09-30 at 21:15 +0200, Dmitry Adamushko wrote:
>
> remove obsolete code -- calc_weighted()
>
Here's another piece of low hanging obsolete fruit.
Remove obsolete TASK_NONINTERACTIVE.
Signed-off-by: Mike Galbraith <[EMAIL PROTECTED]>
diff -uprNX /root/dontdiff
On Sun, 2007-09-30 at 21:15 +0200, Dmitry Adamushko wrote:
remove obsolete code -- calc_weighted()
Here's another piece of low hanging obsolete fruit.
Remove obsolete TASK_NONINTERACTIVE.
Signed-off-by: Mike Galbraith [EMAIL PROTECTED]
diff -uprNX /root/dontdiff
* Mike Galbraith [EMAIL PROTECTED] wrote:
On Sun, 2007-09-30 at 21:15 +0200, Dmitry Adamushko wrote:
remove obsolete code -- calc_weighted()
Here's another piece of low hanging obsolete fruit.
Remove obsolete TASK_NONINTERACTIVE.
Signed-off-by: Mike Galbraith [EMAIL PROTECTED]
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
here is a few patches on top of the recent 'sched-dev':
(1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
dependent on task's static_prio;
(2) [ cleanup ] calc_weighted() is obsolete, remove it;
(3) [ refactoring ] make
and this one,
make dequeue_entity() / enqueue_entity() and update_stats_dequeue() /
update_stats_enqueue() look similar, structure-wise.
zero effect, functionally-wise.
Signed-off-by: Dmitry Adamushko <[EMAIL PROTECTED]>
---
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index
remove obsolete code -- calc_weighted()
Signed-off-by: Dmitry Adamushko <[EMAIL PROTECTED]>
---
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index fe4003d..2674e27 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -342,17 +342,6 @@ update_stats_wait_start(struct cfs_rq
here is a few patches on top of the recent 'sched-dev':
(1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
dependent on task's static_prio;
(2) [ cleanup ] calc_weighted() is obsolete, remove it;
(3) [ refactoring ] make dequeue_entity() / enqueue_entity()
and
here is a few patches on top of the recent 'sched-dev':
(1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
dependent on task's static_prio;
(2) [ cleanup ] calc_weighted() is obsolete, remove it;
(3) [ refactoring ] make dequeue_entity() / enqueue_entity()
and
remove obsolete code -- calc_weighted()
Signed-off-by: Dmitry Adamushko [EMAIL PROTECTED]
---
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index fe4003d..2674e27 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -342,17 +342,6 @@ update_stats_wait_start(struct cfs_rq
and this one,
make dequeue_entity() / enqueue_entity() and update_stats_dequeue() /
update_stats_enqueue() look similar, structure-wise.
zero effect, functionally-wise.
Signed-off-by: Dmitry Adamushko [EMAIL PROTECTED]
---
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index
Ingo Molnar wrote:
Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work
properly then your Xorg will have a load-independent 50% of CPU time all
to itself.
It seems that perhaps that 50% makes more sense on a single/dual CPU
system than on a more robust one, such as a
Ingo Molnar wrote:
Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work
properly then your Xorg will have a load-independent 50% of CPU time all
to itself.
It seems that perhaps that 50% makes more sense on a single/dual CPU
system than on a more robust one, such as a
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> humm... I think, it'd be safer to have something like the following
> change in place.
>
> The thing is that __pick_next_entity() must never be called when
> first_fair(cfs_rq) == NULL. It wouldn't be a problem, should
> 'run_node' be the very
* Dmitry Adamushko [EMAIL PROTECTED] wrote:
humm... I think, it'd be safer to have something like the following
change in place.
The thing is that __pick_next_entity() must never be called when
first_fair(cfs_rq) == NULL. It wouldn't be a problem, should
'run_node' be the very first
On Tue, 2007-09-25 at 11:47 +0200, Ingo Molnar wrote:
> Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work
> properly then your Xorg will have a load-independent 50% of CPU time all
> to itself. (Group scheduling is quite impressive already: i can log in
> as root without
On Tue, 2007-09-25 at 11:47 +0200, Ingo Molnar wrote:
Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work
properly then your Xorg will have a load-independent 50% of CPU time all
to itself. (Group scheduling is quite impressive already: i can log in
as root without
humm... I think, it'd be safer to have something like the following
change in place.
The thing is that __pick_next_entity() must never be called when
first_fair(cfs_rq) == NULL. It wouldn't be a problem, should 'run_node'
be the very first field of 'struct sched_entity' (and it's the second).
On Tue, Sep 25, 2007 at 09:34:20PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 04:44:43PM +0200, Ingo Molnar wrote:
> >
> > The latest sched-devel.git tree can be pulled from:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
> >
>
>
On Tue, Sep 25, 2007 at 04:44:43PM +0200, Ingo Molnar wrote:
>
> The latest sched-devel.git tree can be pulled from:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
>
This is required for it to compile.
---
include/linux/sched.h |1 +
1 files
On Tue, 2007-09-25 at 08:45 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
> > > Lots of scheduler updates in the past few days, done by many people.
> > > Most importantly, the SMP latency problems reported and
On Tue, Sep 25, 2007 at 01:33:06PM +0200, Ingo Molnar wrote:
> > hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
> >
> > p->se.vruntime -= old_rq->cfs.min_vruntime -
> > new_rq->cfs.min_vruntime;
> >
> > needs to become properly group-hierarchy aware?
You seem to have hit the
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This is a quick iteration after yesterday's: a couple of group
scheduling bugs were found/debugged and fixed by Srivatsa Vaddagiri and
Mike Galbraith.
On Tue, Sep 25, 2007 at 03:35:17PM +0200, Mike Galbraith wrote:
> > I tried the following patch. I *think* I see some improvement, wrt
> > latency seen when I type on the shell. Before this patch, I noticed
> > oddities like "kill -9 chew-max-pid" wont kill chew-max (it is queued in
> > runqueue
On Tue, 2007-09-25 at 18:21 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 12:36:17PM +0200, Ingo Molnar wrote:
> > hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
> >
> > p->se.vruntime -= old_rq->cfs.min_vruntime -
> > new_rq->cfs.min_vruntime;
>
> This definitely
On Tue, 2007-09-25 at 14:28 +0200, Mike Galbraith wrote:
> On Tue, 2007-09-25 at 15:58 +0530, Srivatsa Vaddagiri wrote:
>
> > While I try recreating this myself, I wonder if this patch helps?
>
> It didn't here, nor did tweaking root's share. Booting with maxcpus=1,
> I was unable to produce
On Tue, Sep 25, 2007 at 12:36:17PM +0200, Ingo Molnar wrote:
> hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
>
> p->se.vruntime -= old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;
This definitely does need some fixup, even though I am not sure yet if
it will solve
On Tue, 2007-09-25 at 15:58 +0530, Srivatsa Vaddagiri wrote:
> While I try recreating this myself, I wonder if this patch helps?
It didn't here, nor did tweaking root's share. Booting with maxcpus=1,
I was unable to produce large latencies, but didn't try very many
things.
-Mike
-
To
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
>
> p->se.vruntime -= old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;
>
> needs to become properly group-hierarchy aware?
a quick first stab like the one below does not appear to
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> > This doornails the Vaio. After grub handover the screen remains black
> > and the fan goes whir.
> >
> > http://userweb.kernel.org/~akpm/config-sony.txt
>
> This seems to be UP
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
> > 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)
On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
> 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) {}' &
>
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Srivatsa Vaddagiri <[EMAIL PROTECTED]> 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
On Tue, 2007-09-25 at 11:47 +0200, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
> >
> > > > [...] Latencies of up to 336ms hit me during the recompile (make -j3),
> > > > with nothing else running. Since reboot,
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
>
> > > [...] Latencies of up to 336ms hit me during the recompile (make -j3),
> > > with nothing else running. Since reboot, latencies are, so far, very
> > > very nice. [...]
> >
> > 'very
* Srivatsa Vaddagiri <[EMAIL PROTECTED]> 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%
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
* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
> Seems like following trivial change needed to compile without
> CONFIG_SCHEDSTATS
>
> [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK
On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
> > [...] Latencies of up to 336ms hit me during the recompile (make -j3),
> > with nothing else running. Since reboot, latencies are, so far, very
> > very nice. [...]
>
> 'very very nice' == 'best ever' ? :-)
Yes. Very VERY nice feel.
On Tue, 2007-09-25 at 14:41 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
> > On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > > > Darn, have news: latency thing isn't dead. Two busy loops, one at nice
> > > > 0 pinned to
On Tue, 2007-09-25 at 14:23 +0530, Srivatsa Vaddagiri wrote:
> Mike,
> Do you have FAIR_USER_SCHED turned on as well? Can you send me
> your .config pls?
I did have. gzipped config attached.. this is current though, after
disabling groups. I'm still beating on the basic changes (boy does
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > sched_debug (attached) is.. strange.
>
> Disabling CONFIG_FAIR_GROUP_SCHED fixed both. [...]
heh. Evil plan to enable the group scheduler by default worked out as
planned! ;-) [guess how many container users would do ... interactivity
tests
On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > > Darn, have news: latency thing isn't dead. Two busy loops, one at nice
> > > 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> > > latencies
On Tue, 25 Sep 2007 14:13:27 +0530 Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> > This doornails the Vaio. After grub handover the screen remains black
> > and the fan goes whir.
> >
> >
On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > Darn, have news: latency thing isn't dead. Two busy loops, one at nice
> > 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> > latencies below for nice -5 Xorg. Didn't kill the box though.
> >
> > se.wait_max
On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> This doornails the Vaio. After grub handover the screen remains black
> and the fan goes whir.
>
> http://userweb.kernel.org/~akpm/config-sony.txt
This seems to be UP regression. Sorry abt that. I could recreate
the problem very
On Tue, 2007-09-25 at 09:35 +0200, Mike Galbraith wrote:
> Darn, have news: latency thing isn't dead. Two busy loops, one at nice
> 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> latencies below for nice -5 Xorg. Didn't kill the box though.
>
> se.wait_max :
On Mon, 24 Sep 2007 23:45:37 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> The latest sched-devel.git tree can be pulled from:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This doornails the Vaio. After grub handover the screen remains black
and the
On Tue, 2007-09-25 at 08:10 +0200, Mike Galbraith wrote:
> no news is good news.
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for nice -5 Xorg. Didn't kill the box though.
se.wait_max
Hi;
25 Eyl 2007 Sal tarihinde, Ingo Molnar şunları yazmıştı:
>
> The latest sched-devel.git tree can be pulled from:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
>
> Lots of scheduler updates in the past few days, done by many people.
> Most
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
> > Lots of scheduler updates in the past few days, done by many people.
> > Most importantly, the SMP latency problems reported and debugged by
> > Mike
> > Galbraith should be fixed for good
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
> Mike Galbraith (2):
> sched: fix SMP migration latencies
> sched: fix formatting of /proc/sched_debug
Off-by-one bug in attribution, rocks and sticks (down boy!) don't
count ;-) I just built, and will spend the morning beating
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
Mike Galbraith (2):
sched: fix SMP migration latencies
sched: fix formatting of /proc/sched_debug
Off-by-one bug in attribution, rocks and sticks (down boy!) don't
count ;-) I just built, and will spend the morning beating on
* Daniel Walker [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
Lots of scheduler updates in the past few days, done by many people.
Most importantly, the SMP latency problems reported and debugged by
Mike
Galbraith should be fixed for good now.
Does
Hi;
25 Eyl 2007 Sal tarihinde, Ingo Molnar şunları yazmıştı:
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
Lots of scheduler updates in the past few days, done by many people.
Most importantly,
On Tue, 2007-09-25 at 08:10 +0200, Mike Galbraith wrote:
no news is good news.
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for nice -5 Xorg. Didn't kill the box though.
se.wait_max
On Mon, 24 Sep 2007 23:45:37 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This doornails the Vaio. After grub handover the screen remains black
and the fan
On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
This doornails the Vaio. After grub handover the screen remains black
and the fan goes whir.
http://userweb.kernel.org/~akpm/config-sony.txt
This seems to be UP regression. Sorry abt that. I could recreate
the problem very
On Tue, 2007-09-25 at 09:35 +0200, Mike Galbraith wrote:
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for nice -5 Xorg. Didn't kill the box though.
se.wait_max :
On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for nice -5 Xorg. Didn't kill the box though.
se.wait_max
On Tue, 25 Sep 2007 14:13:27 +0530 Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
This doornails the Vaio. After grub handover the screen remains black
and the fan goes whir.
http://userweb.kernel.org/~akpm/config-sony.txt
On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for
On Tue, 2007-09-25 at 14:23 +0530, Srivatsa Vaddagiri wrote:
Mike,
Do you have FAIR_USER_SCHED turned on as well? Can you send me
your .config pls?
I did have. gzipped config attached.. this is current though, after
disabling groups. I'm still beating on the basic changes (boy does it
* Mike Galbraith [EMAIL PROTECTED] wrote:
sched_debug (attached) is.. strange.
Disabling CONFIG_FAIR_GROUP_SCHED fixed both. [...]
heh. Evil plan to enable the group scheduler by default worked out as
planned! ;-) [guess how many container users would do ... interactivity
tests like you
On Tue, 2007-09-25 at 14:41 +0530, Srivatsa Vaddagiri wrote:
On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
Darn, have news: latency thing isn't dead. Two busy loops, one at nice
0 pinned to CPU0, and
On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
[...] Latencies of up to 336ms hit me during the recompile (make -j3),
with nothing else running. Since reboot, latencies are, so far, very
very nice. [...]
'very very nice' == 'best ever' ? :-)
Yes. Very VERY nice feel.
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
Seems like following trivial change needed to compile without
CONFIG_SCHEDSTATS
[EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK
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
* Srivatsa Vaddagiri [EMAIL PROTECTED] 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
* Mike Galbraith [EMAIL PROTECTED] wrote:
On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
[...] Latencies of up to 336ms hit me during the recompile (make -j3),
with nothing else running. Since reboot, latencies are, so far, very
very nice. [...]
'very very nice' ==
On Tue, 2007-09-25 at 11:47 +0200, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
[...] Latencies of up to 336ms hit me during the recompile (make -j3),
with nothing else running. Since reboot, latencies are, so
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Srivatsa Vaddagiri [EMAIL PROTECTED] 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
On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
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
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
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) {}'
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
This doornails the Vaio. After grub handover the screen remains black
and the fan goes whir.
http://userweb.kernel.org/~akpm/config-sony.txt
This seems to be UP regression.
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
p-se.vruntime -= old_rq-cfs.min_vruntime - new_rq-cfs.min_vruntime;
needs to become properly group-hierarchy aware?
a quick first stab like the one below does not appear to solve the
On Tue, 2007-09-25 at 15:58 +0530, Srivatsa Vaddagiri wrote:
While I try recreating this myself, I wonder if this patch helps?
It didn't here, nor did tweaking root's share. Booting with maxcpus=1,
I was unable to produce large latencies, but didn't try very many
things.
-Mike
-
To
On Tue, Sep 25, 2007 at 12:36:17PM +0200, Ingo Molnar wrote:
hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
p-se.vruntime -= old_rq-cfs.min_vruntime - new_rq-cfs.min_vruntime;
This definitely does need some fixup, even though I am not sure yet if
it will solve completely the
On Tue, 2007-09-25 at 14:28 +0200, Mike Galbraith wrote:
On Tue, 2007-09-25 at 15:58 +0530, Srivatsa Vaddagiri wrote:
While I try recreating this myself, I wonder if this patch helps?
It didn't here, nor did tweaking root's share. Booting with maxcpus=1,
I was unable to produce large
On Tue, 2007-09-25 at 18:21 +0530, Srivatsa Vaddagiri wrote:
On Tue, Sep 25, 2007 at 12:36:17PM +0200, Ingo Molnar wrote:
hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
p-se.vruntime -= old_rq-cfs.min_vruntime -
new_rq-cfs.min_vruntime;
This definitely does need
On Tue, Sep 25, 2007 at 03:35:17PM +0200, Mike Galbraith wrote:
I tried the following patch. I *think* I see some improvement, wrt
latency seen when I type on the shell. Before this patch, I noticed
oddities like kill -9 chew-max-pid wont kill chew-max (it is queued in
runqueue waiting for
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This is a quick iteration after yesterday's: a couple of group
scheduling bugs were found/debugged and fixed by Srivatsa Vaddagiri and
Mike Galbraith.
On Tue, Sep 25, 2007 at 01:33:06PM +0200, Ingo Molnar wrote:
hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
p-se.vruntime -= old_rq-cfs.min_vruntime -
new_rq-cfs.min_vruntime;
needs to become properly group-hierarchy aware?
You seem to have hit the nerve for this
On Tue, 2007-09-25 at 08:45 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
Lots of scheduler updates in the past few days, done by many people.
Most importantly, the SMP latency problems reported and debugged by
On Tue, Sep 25, 2007 at 04:44:43PM +0200, Ingo Molnar wrote:
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This is required for it to compile.
---
include/linux/sched.h |1 +
1 files changed,
On Tue, Sep 25, 2007 at 09:34:20PM +0530, Srivatsa Vaddagiri wrote:
On Tue, Sep 25, 2007 at 04:44:43PM +0200, Ingo Molnar wrote:
The latest sched-devel.git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
This is
humm... I think, it'd be safer to have something like the following
change in place.
The thing is that __pick_next_entity() must never be called when
first_fair(cfs_rq) == NULL. It wouldn't be a problem, should 'run_node'
be the very first field of 'struct sched_entity' (and it's the second).
On Mon, 2007-09-24 at 23:45 +0200, Ingo Molnar wrote:
> Lots of scheduler updates in the past few days, done by many people.
> Most importantly, the SMP latency problems reported and debugged by
> Mike
> Galbraith should be fixed for good now.
Does this have anything to do with idle balancing
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007 23:45:37 +0200
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > The latest sched-devel.git tree can be pulled from:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
>
> I'm pulling
1 - 100 of 106 matches
Mail list logo
