Well, I am now running a 2.6.22 (without cfs) and could now see it once
(within a month...) that exactly the same message from konqueror was
produced.
So I think its a general problem of konqueror that was hidden and
somehow its triggered much more often with the cfs.
I just wonder why nobody e
> could you send me your debug-info:
>
> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
>
> just run that script on 2.6.23-rc2 system and send me the file it
> produces. I've got a theory about what might be going on, and this
> debug-info could help prove/disprove it.
D
* Markus <[EMAIL PROTECTED]> wrote:
> Well, I am back now, but the problem still exists in 2.6.23-rc2. And
> as there is nothing more I can do thats it for now.
could you send me your debug-info:
http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
just run that script on 2.
Well, I am back now, but the problem still exists in 2.6.23-rc2.
And as there is nothing more I can do thats it for now.
Markus
-
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/
> hm, Markus indicated that he tried the v2.6.21.6-cfsv19 patch, and
that
> does not include the time.c change. Markus - does your kernel include
> the code below? (if yes, please revert it via patch -p1 -R )
As already said, 2.6.22.1-cfs-v19 includes the patch and
2.6.21.6-cfs-v19 does not in
Ingo Molnar wrote:
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
Does the patch below help?
Spectacularly no! With this patch the "glitch1" script with multiple
scrolling windows has all xterms and glxgears stop totally dead for
~200ms once per second. I didn't properly test anything else after
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Bill Davidsen wrote:
> >Ingo Molnar wrote:
> >>* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> >>
> Does the patch below help?
> >
> >Doesn't seem to apply against 2.6.22.1, I'm trying 2.6.22.6 as soon as
> >I recreate it.
>
> Applied to 2.6.22-git9
Bill Davidsen wrote:
Ingo Molnar wrote:
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
Does the patch below help?
Doesn't seem to apply against 2.6.22.1, I'm trying 2.6.22.6 as soon as
I recreate it.
Applied to 2.6.22-git9, building now.
-
To unsubscribe from this list: send the line "unsubsc
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> >
> >>>Does the patch below help?
>
> Doesn't seem to apply against 2.6.22.1, I'm trying 2.6.22.6 as soon as
> I recreate it.
the patch below is merged against 2.6.22.1-cfs-v19 - doe
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> >
> >>>Does the patch below help?
>
> Doesn't seem to apply against 2.6.22.1, I'm trying 2.6.22.6 as soon as
> I recreate it.
hm, it's against recent -git.
dont waste your time on 2
Ingo Molnar wrote:
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
Does the patch below help?
Doesn't seem to apply against 2.6.22.1, I'm trying 2.6.22.6 as soon as I
recreate it.
Spectacularly no! With this patch the "glitch1" script with multiple
scrolling windows has all xterms and glxgears
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Does the patch below help?
>
> Spectacularly no! With this patch the "glitch1" script with multiple
> scrolling windows has all xterms and glxgears stop totally dead for
> ~200ms once per second. I didn't properly test anything else after
> that.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > ah! It passes in a low-res time source into a high-res time
> > interface (pthread_cond_timedwait()). Could you change the
> > time(NULL) + 1 to time(NULL) + 2, or change it to:
> >
> > gettimeofday(&wait, NULL);
> > wait.tv_sec++;
>
> T
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > Does the patch below help?
>
> Spectacularly no! With this patch the "glitch1" script with multiple
> scrolling windows has all xterms and glxgears stop totally dead for
> ~200ms once per second. I didn't properly test anything else after
> that.
Linus Torvalds wrote:
On Tue, 17 Jul 2007, Ingo Molnar wrote:
* Ian Kent <[EMAIL PROTECTED]> wrote:
In several places I have code similar to:
wait.tv_sec = time(NULL) + 1;
wait.tv_nsec = 0;
Ok, that definitely should work.
Does the patch below help?
Spectacularly no! With
On Wed, 2007-07-18 at 09:03 -0700, Linus Torvalds wrote:
>
> On Tue, 17 Jul 2007, Ingo Molnar wrote:
> >
> > * Ian Kent <[EMAIL PROTECTED]> wrote:
> > >
> > > In several places I have code similar to:
> > >
> > > wait.tv_sec = time(NULL) + 1;
> > > wait.tv_nsec = 0;
>
> Ok, that definitely sho
On Wed, 18 Jul 2007, Ingo Molnar wrote:
>
> Linus, Thomas, what do you think, should we keep the time.c change?
No, not if it's off by the second field. That 30% CPU usage indicates that
there's some nasty bug there somewhere, and that's just not worth it.
If time() cannot get the second fie
On Tue, 17 Jul 2007, Ingo Molnar wrote:
>
> * Ian Kent <[EMAIL PROTECTED]> wrote:
> >
> > In several places I have code similar to:
> >
> > wait.tv_sec = time(NULL) + 1;
> > wait.tv_nsec = 0;
Ok, that definitely should work.
Does the patch below help?
> ah! It passes in a low-res time sourc
Ingo Molnar wrote:
* Ian Kent <[EMAIL PROTECTED]> wrote:
ah! It passes in a low-res time source into a high-res time
interface (pthread_cond_timedwait()). Could you change the
time(NULL) + 1 to time(NULL) + 2, or change it to:
gettimeofday(&wait, NULL);
wait.tv_sec++;
doe
* Ian Kent <[EMAIL PROTECTED]> wrote:
> > > ah! It passes in a low-res time source into a high-res time
> > > interface (pthread_cond_timedwait()). Could you change the
> > > time(NULL) + 1 to time(NULL) + 2, or change it to:
> > >
> > > gettimeofday(&wait, NULL);
> > > wait.tv_sec++;
> > >
On Tue, 2007-07-17 at 21:24 -0400, Bill Davidsen wrote:
> Ingo Molnar wrote:
> > * Ian Kent <[EMAIL PROTECTED]> wrote:
> >
> >
> >>> ah! It passes in a low-res time source into a high-res time interface
> >>> (pthread_cond_timedwait()). Could you change the time(NULL) + 1 to
> >>> time(NULL) +
On Tue, 2007-07-17 at 14:16 -0700, David Schwartz wrote:
> > * Ian Kent <[EMAIL PROTECTED]> wrote:
> >
> > > Yes it does and I have two reported bugs so far.
> > >
> > > In several places I have code similar to:
> > >
> > > wait.tv_sec = time(NULL) + 1;
> > > wait.tv_nsec = 0;
> > >
> > > signaled
Ingo Molnar wrote:
* Ian Kent <[EMAIL PROTECTED]> wrote:
ah! It passes in a low-res time source into a high-res time interface
(pthread_cond_timedwait()). Could you change the time(NULL) + 1 to
time(NULL) + 2, or change it to:
gettimeofday(&wait, NULL);
wait.tv_sec++;
> hm, Markus indicated that he tried the v2.6.21.6-cfsv19 patch, and
that
> does not include the time.c change. Markus - does your kernel include
> the code below? (if yes, please revert it via patch -p1 -R )
Well, the 2.6.22.1-cfs-v19 does include it, but the 2.6.21.6-cfs-v19
does not have tha
Hi Ingo,
sorry for the long delay, I've spent a week doing non-kernel work.
On Tue, Jul 10, 2007 at 12:39:50AM +0200, Ingo Molnar wrote:
>
> * Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
> > > The biggest user-visible change in -v19 is reworked sleeper
> > > fairness: it's similar in behavior t
> * Ian Kent <[EMAIL PROTECTED]> wrote:
>
> > Yes it does and I have two reported bugs so far.
> >
> > In several places I have code similar to:
> >
> > wait.tv_sec = time(NULL) + 1;
> > wait.tv_nsec = 0;
> >
> > signaled = 0;
> > while (!signaled) {
> > status = pthread_cond_timedwait(&co
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But why does that happen? And why would the scheduler have *anything*
> to do with this? No idea. Maybe timing. Maybe the time.c changes.
> Dunno.
hm, Markus indicated that he tried the v2.6.21.6-cfsv19 patch, and that
does not include the time.c
On Tue, 17 Jul 2007, Ingo Molnar wrote:
>
> i think the problem starts here:
>
> 11902 1184699865.141939 read(3, "", 32) = 0 <0.07>
Well, it's preceded by a poll() that says that it has a POLLHUP event, so
that socket would seem to have simply been closed from the other end.
There's al
> 9173 1184675906.194424 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS,
0x7fff341af5c0)
> = -1 ENOTTY (Inappropriate ioctl for device) <0.06>
> 9173 1184675906.194463 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS,
0x7fff341af5c0)
> = -1 ENOTTY (Inappropriate ioctl for device) <0.04>
>
> ? Are those
* Ian Kent <[EMAIL PROTECTED]> wrote:
> > ah! It passes in a low-res time source into a high-res time interface
> > (pthread_cond_timedwait()). Could you change the time(NULL) + 1 to
> > time(NULL) + 2, or change it to:
> >
> > gettimeofday(&wait, NULL);
> > wait.tv_sec++;
>
> OK, I'm
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i think it fails here due to some IO error:
>
> 9173 1184675906.674610 write(2, "konqueror: Fatal IO error:
> clien"..., 41) = 41 <0.07>
oh, and i missed the obvious request: could you start konqueror from a
terminal and see what it prints when
* Markus <[EMAIL PROTECTED]> wrote:
> > > Nothing is printed for a disapeared app for me.
> > >
> > > Is there anything more I can try?
> >
> > sure - could you start one of those apps via:
> >
> > strace -ttt -TTT -o trace.log -f
> >
> > and wait for it to "disappear"? Then compress the
On 07/17/2007 03:45 AM, Ingo Molnar wrote:
> * Ian Kent <[EMAIL PROTECTED]> wrote:
>
>> Yes it does and I have two reported bugs so far.
>>
>> In several places I have code similar to:
>>
>> wait.tv_sec = time(NULL) + 1;
>> wait.tv_nsec = 0;
>>
>> signaled = 0;
>> while (!signaled) {
>> st
> could you please send me the cfs-debug-info output nevertheless?
private mail (4,9K)
> > Nothing is printed for a disapeared app for me.
> >
> > Is there anything more I can try?
>
> sure - could you start one of those apps via:
>
> strace -ttt -TTT -o trace.log -f
>
> and wait for it
On Tue, 2007-07-17 at 09:45 +0200, Ingo Molnar wrote:
> * Ian Kent <[EMAIL PROTECTED]> wrote:
>
> > Yes it does and I have two reported bugs so far.
> >
> > In several places I have code similar to:
> >
> > wait.tv_sec = time(NULL) + 1;
> > wait.tv_nsec = 0;
> >
> > signaled = 0;
> > while (!si
* Ian Kent <[EMAIL PROTECTED]> wrote:
> Yes it does and I have two reported bugs so far.
>
> In several places I have code similar to:
>
> wait.tv_sec = time(NULL) + 1;
> wait.tv_nsec = 0;
>
> signaled = 0;
> while (!signaled) {
> status = pthread_cond_timedwait(&cond, &mutex, &wait);
* Markus <[EMAIL PROTECTED]> wrote:
> The dmesg output is not differing in any interesting point (just some
> numbers, like raid-benchmark, some irqs or usb-numbers...)
could you please send me the cfs-debug-info output nevertheless?
> Nothing is printed for a disapeared app for me.
>
> Is th
On Mon, 2007-07-16 at 23:55 +0200, Ingo Molnar wrote:
> * Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > On 07/13/2007 05:19 PM, Bill Davidsen wrote:
> > >
> > > I should really go back to 2.6.21.6, 2.6.22 has many bizarre behaviors
> > > with FC6. Automount starts taking 30% of CPU (unused at the
Ingo Molnar wrote:
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
On 07/13/2007 05:19 PM, Bill Davidsen wrote:
I should really go back to 2.6.21.6, 2.6.22 has many bizarre behaviors
with FC6. Automount starts taking 30% of CPU (unused at the moment)
Can you confirm whether CFS is inv
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 07/13/2007 05:19 PM, Bill Davidsen wrote:
> >
> > I should really go back to 2.6.21.6, 2.6.22 has many bizarre behaviors
> > with FC6. Automount starts taking 30% of CPU (unused at the moment)
>
> Can you confirm whether CFS is involved, i.e. does
On 07/13/2007 05:19 PM, Bill Davidsen wrote:
>
> I should really go back to 2.6.21.6, 2.6.22 has many bizarre behaviors
> with FC6. Automount starts taking 30% of CPU (unused at the moment)
Can you confirm whether CFS is involved, i.e. does it spin like that
even without the CFS patch applied?
-
> > [...] The mouse is smooth, just when one app is being quit (dont
> > know why...) the mouse will be jerking for a few seconds...
> is the mouse jerky on any app quitting?
No.
> Or is your observation the following: _sometimes_ apps quit
> unexpectedly (their window just vanishes?), and _at
On Monday 16 July 2007 05:17, Ingo Molnar wrote:
>
> * Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> > I run a java application at nice 15. Its been a background
> > application here for as long as SD and CFS have been around. If I
> > have a compile running at nice 0, with v19 java gets so lit
* Markus <[EMAIL PROTECTED]> wrote:
> [...] The mouse is smooth, just when one app is being quit (dont know
> why...) the mouse will be jerking for a few seconds...
is the mouse jerky on any app quitting? Or is your observation the
following: _sometimes_ apps quit unexpectedly (their window ju
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> I run a java application at nice 15. Its been a background
> application here for as long as SD and CFS have been around. If I
> have a compile running at nice 0, with v19 java gets so little cpu
> that the the wrapper that runs to monitor it is ti
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> Sending a few seconds of logged /proc/sched_debug will also help get a
> picture of what's happening, and lovely would be a method to reproduce
> the problem locally.
also, by running this script:
http://people.redhat.com/mingo/cfs-scheduler/to
On Sun, 2007-07-15 at 23:11 +0200, Markus wrote:
> > > [1] http://lkml.org/lkml/2007/07/14/60
> >
> > Hm. Tasks disappearing isn't you're typical process scheduler problem
> > by any means, nor is an idle box exhibiting mouse "lurchiness". Is
> > there anything unusual in your logs?
>
> I know
> > [1] http://lkml.org/lkml/2007/07/14/60
>
> Hm. Tasks disappearing isn't you're typical process scheduler problem
> by any means, nor is an idle box exhibiting mouse "lurchiness". Is
> there anything unusual in your logs?
I know that its not typical, but when my current kernel is stable and
On Sun, 2007-07-15 at 14:53 +0200, Markus wrote:
> [1] http://lkml.org/lkml/2007/07/14/60
Hm. Tasks disappearing isn't you're typical process scheduler problem
by any means, nor is an idle box exhibiting mouse "lurchiness". Is
there anything unusual in your logs?
-Mike
-
To unsubscribe
> Sending a few seconds of logged /proc/sched_debug will also help get a
> picture of what's happening, and lovely would be a method to reproduce
> the problem locally.
Hi. Is there anything like the sched_debug in the 2.6.22-git5?
Because I have a cfs-problem as well [1].
Markus
[1] http://
On Sat, 2007-07-14 at 13:19 -0400, Ed Tomlinson wrote:
> Hi,
Hi Ed,
> I run a java application at nice 15. Its been a background application here
> for as long
> as SD and CFS have been around. If I have a compile running at nice 0, with
> v19 java
> gets so little cpu that the the wrapper t
Hi,
I run a java application at nice 15. Its been a background application here
for as long
as SD and CFS have been around. If I have a compile running at nice 0, with
v19 java
gets so little cpu that the the wrapper that runs to monitor it is timing out
waiting for
it to start. This is ne
> I'll try a git snapshot next, but is there a way I can get more
output?
Did it. The mouse is smooth, just when one app is being quit (dont know
why...) the mouse will be jerking for a few seconds...
So, is there any way to get a more verbose output regarding the cfs?
Markus
-
To unsubscrib
> i'm pleased to announce release -v19 of the CFS scheduler patchset.
>
> The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7,
> v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the
> usual place:
>
> http://people.redhat.com/mingo/cfs-scheduler/
Well, I took a 2
Ingo Molnar wrote:
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
I've taken mainline git tree (freshly integrated CFS!) out for a
multimedia spin. I tested watching movies and listenign to music in
the presence of various sleep/burn loads, pure burn loads, and mixed
loads. All was peachy here..
Ingo Molnar wrote:
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
I've taken mainline git tree (freshly integrated CFS!) out for a
multimedia spin. I tested watching movies and listenign to music in
the presence of various sleep/burn loads, pure burn loads, and mixed
loads. All was peachy her
* Bill Davidsen <[EMAIL PROTECTED]> wrote:
> > I've taken mainline git tree (freshly integrated CFS!) out for a
> > multimedia spin. I tested watching movies and listenign to music in
> > the presence of various sleep/burn loads, pure burn loads, and mixed
> > loads. All was peachy here.. I s
Mike Galbraith wrote:
Greetings,
On Fri, 2007-07-06 at 19:33 +0200, Ingo Molnar wrote:
i'm pleased to announce release -v19 of the CFS scheduler patchset.
I've taken mainline git tree (freshly integrated CFS!) out for a
multimedia spin. I tested watching movies and listenign to music in the
Greetings,
On Fri, 2007-07-06 at 19:33 +0200, Ingo Molnar wrote:
> i'm pleased to announce release -v19 of the CFS scheduler patchset.
I've taken mainline git tree (freshly integrated CFS!) out for a
multimedia spin. I tested watching movies and listenign to music in the
presence of various slee
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> > The biggest user-visible change in -v19 is reworked sleeper
> > fairness: it's similar in behavior to -v18 but works more
> > consistently across nice levels. Fork-happy workloads (like kernel
> > builds) should behave better as well. There are al
Ingo Molnar wrote:
> The biggest user-visible change in -v19 is reworked sleeper fairness:
> it's similar in behavior to -v18 but works more consistently across nice
> levels. Fork-happy workloads (like kernel builds) should behave better
> as well. There are also a handful of speedups: unsigned ma
Hi Ingo !
On Fri, Jul 06, 2007 at 07:33:19PM +0200, Ingo Molnar wrote:
>
> i'm pleased to announce release -v19 of the CFS scheduler patchset.
>
> The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7,
> v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the
> usual pla
i'm pleased to announce release -v19 of the CFS scheduler patchset.
The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7,
v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the
usual place:
http://people.redhat.com/mingo/cfs-scheduler/
The biggest user-visible ch
63 matches
Mail list logo
