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
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
> 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.
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.
Done by
* 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
* 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
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
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
> 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
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
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
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
* 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 -
* 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
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
* 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(, NULL);
> > wait.tv_sec++;
>
> This
* 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.
* 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. Since the
* 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++;
This is wrong.
* 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.
Bill,
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:
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.6.21.6-cfsv19,
* 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 - does it solve the
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
* 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, building now.
ok,
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
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!
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
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
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
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(, NULL);
wait.tv_sec++;
does
* 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(, 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
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 = 0;
while (!signaled) {
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) + 2, or change it to:
* 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++;
does this solve the
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++;
does
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 source into a
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
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 should work.
Does the
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
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(, 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
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
> * 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(,
* 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
> 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(, 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
* 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
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) {
>>
> 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
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
* 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(, , );
>if
* 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
* 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 there
* 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);
if
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 (!signaled) {
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 app
and wait for it to
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) {
status =
* 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 app
and wait for it to disappear? Then compress the trace.log via
* 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 it goes
* 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 with you,
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 -ENOTTY
* 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
* 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);
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 to -v18 but
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 that
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++;
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
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
* 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
* 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
* 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
* 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:
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
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 that its not
* 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:
* 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 timing
* 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 just
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 little cpu
[...] 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 the
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?
-
* 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 it spin
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
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 moment)
> > [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
> 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]
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]
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
[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
shows
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
1 - 100 of 125 matches
Mail list logo
