Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Frans Pop <[EMAIL PROTECTED]> wrote:
>
>> On Monday 29 October 2007, Balbir Singh wrote:
>> > We'll also need this additional patch (untested),
>>
>> OK. Both patches together do the trick. Gave it a nice long test run and got
>> no more weirdness.
>>
Christian Borntraeger wrote:
> Am Montag, 29. Oktober 2007 schrieb Balbir Singh:
>> We'll also need this additional patch (untested), but in the long run
>> I think the approach needs to be
>>
>> 1. Update stime and utime at the time of context switching -- keep it
>>in sync with p->sum_exec_ru
Am Montag, 29. Oktober 2007 schrieb Balbir Singh:
> We'll also need this additional patch (untested), but in the long run
> I think the approach needs to be
>
> 1. Update stime and utime at the time of context switching -- keep it
>in sync with p->sum_exec_runtime
> 2. Keep track of system/use
Frans Pop wrote:
> On Monday 29 October 2007, Balbir Singh wrote:
>> We'll also need this additional patch (untested),
>
> OK. Both patches together do the trick. Gave it a nice long test run and got
> no more weirdness.
> Tested-by: Frans Pop <[EMAIL PROTECTED]>
>
Thanks for testing it
Ingo,
* Frans Pop <[EMAIL PROTECTED]> wrote:
> On Monday 29 October 2007, Balbir Singh wrote:
> > We'll also need this additional patch (untested),
>
> OK. Both patches together do the trick. Gave it a nice long test run and got
> no more weirdness.
> Tested-by: Frans Pop <[EMAIL PROTECTED]>
cool, t
On Monday 29 October 2007, Balbir Singh wrote:
> We'll also need this additional patch (untested),
OK. Both patches together do the trick. Gave it a nice long test run and got
no more weirdness.
Tested-by: Frans Pop <[EMAIL PROTECTED]>
> but in the long run I think the approach needs to be
>
> 1
On Mon, Oct 29, 2007 at 09:04:25PM +0100, Ingo Molnar wrote:
>
> * Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> > We'll I initially thought of it and then I remembered that the
> > regression occurs only when the accounting itself is inaccurate. I am
> > tempted to ack the removal, but I would l
On Monday 29 October 2007, Ingo Molnar wrote:
> * Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> > > - return clock_t_to_cputime(utime);
> > > + p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
> > > + return p->prev_utime;
> > > }
> >
> > [...]
> >
> > I dont think it will work.
On Mon, 2007-10-29 at 21:41 +0100, Ingo Molnar wrote:
> * Christian Borntraeger <[EMAIL PROTECTED]> wrote:
>
> > > - return clock_t_to_cputime(utime);
> > > + p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
> > > + return p->prev_utime;
> > > }
> > [...]
> >
> > I dont think it w
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> > - return clock_t_to_cputime(utime);
> > + p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
> > + return p->prev_utime;
> > }
> [...]
>
> I dont think it will work. It will make utime monotic, but stime can
> still decre
Am Montag, 29. Oktober 2007 schrieb Ingo Molnar:
> i've got a patch from Peter queued up. (see below) This should fix the
> main issue.
[...]
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -358,7 +358,8 @@ static cputime_t task_utime(struct task_
> }
> utime = (clock
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> We'll I initially thought of it and then I remembered that the
> regression occurs only when the accounting itself is inaccurate. I am
> tempted to ack the removal, but I would like to get input from others.
> Meanwhile, I'll try and see if I can fix
Frans Pop wrote:
> Hello Balbir,
[snip]
> Any progress on this issue? I noticed that it's still there in current git.
>
I have been looking elsewhere, sorry, I'll look into this issue tonight
> If a better implementation is not expected any time soon, how about an ACK
> on the reversion patch
Hello Balbir,
On Tuesday 16 October 2007, Balbir Singh wrote:
> Christian Borntraeger wrote:
> > Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh:
> >> I am trying to think out loud as to what the root cause of the problem
> >> might be. In one of the discussion threads, I saw utime going
> >> b
Christian Borntraeger wrote:
> Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh:
>> I am trying to think out loud as to what the root cause of the problem
>> might be. In one of the discussion threads, I saw utime going backwards,
>> which seemed very odd, I suspect that those are rounding errors
Frans Pop wrote:
> On Tuesday 16 October 2007, Balbir Singh wrote:
>> I am trying to think out loud as to what the root cause of the problem
>> might be. In one of the discussion threads, I saw utime going backwards,
>> which seemed very odd, I suspect that those are rounding errors.
>
> I only re
Am Dienstag, 16. Oktober 2007 schrieb Balbir Singh:
> I am trying to think out loud as to what the root cause of the problem
> might be. In one of the discussion threads, I saw utime going backwards,
> which seemed very odd, I suspect that those are rounding errors.
>
> I don't understand your exp
On Tuesday 16 October 2007, Balbir Singh wrote:
> I am trying to think out loud as to what the root cause of the problem
> might be. In one of the discussion threads, I saw utime going backwards,
> which seemed very odd, I suspect that those are rounding errors.
I only remembered stime going backw
Christian Borntraeger wrote:
> Chuck, Balbir,
>
> we still have a problem with stime occosionally going backwards. I stated
> below that I think this is not fixable with the current utime/stime split
> algorithm.
>
Hi,
I missed seeing this problem before, sorry about that. Thanks for the
link b
Chuck, Balbir,
we still have a problem with stime occosionally going backwards. I stated
below that I think this is not fixable with the current utime/stime split
algorithm.
Balbir, you wrote this code, Chuck you tried to fix it. Any ideas how to
fix this properly? The only idea I have requires t
Am Samstag, 13. Oktober 2007 schrieb Frans Pop:
> > > Please consider this patch for 2.6.23.2
> > > http://lkml.org/lkml/2007/10/4/389
> > Is it already in Linus's tree? If so, do you have a git commit id? If
> > not, please let us (stable@) know when it is, and what the id is, and
> > then we ca
On Friday 12 October 2007, Greg KH wrote:
> On Fri, Oct 12, 2007 at 10:31:50PM +0200, Frans Pop wrote:
> > Please consider this patch for 2.6.23.2
> > http://lkml.org/lkml/2007/10/4/389
> >
> > tested by me in
> > http://lkml.org/lkml/2007/10/5/150
> >
> > to fix the regression first reported in
>
On Fri, Oct 12, 2007 at 10:31:50PM +0200, Frans Pop wrote:
> Please consider this patch for 2.6.23.2
> http://lkml.org/lkml/2007/10/4/389
>
> tested by me in
> http://lkml.org/lkml/2007/10/5/150
>
> to fix the regression first reported in
> http://lkml.org/lkml/2007/10/3/123
>
> Cause of the wro
Please consider this patch for 2.6.23.2
http://lkml.org/lkml/2007/10/4/389
tested by me in
http://lkml.org/lkml/2007/10/5/150
to fix the regression first reported in
http://lkml.org/lkml/2007/10/3/123
Cause of the wrong display in top is the value of stime in /proc//stat
decreasing occasionally
Il Thu, Oct 04, 2007 at 01:32:44AM +0200, Frans Pop ha scritto:
> On Wednesday 03 October 2007, you wrote:
> > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote:
> > > On Wednesday 03 October 2007, you wrote:
> > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > > > > On Wed, 3 Oct 2007, Fr
On Wednesday 03 October 2007, you wrote:
> On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote:
> > On Wednesday 03 October 2007, you wrote:
> > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > > > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > > > The only change is in 2 consecutive columns: "2911
On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > > The only change is in 2 consecutive columns: "2911 502" -> "2912
> > > > 500". Is processor usage cal
On Wednesday 03 October 2007, you wrote:
> On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > The only change is in 2 consecutive columns: "2911 502" -> "2912
> > > 500". Is processor usage calculated from those? Can someone explain
> > > how?
> >
> > The latter
On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> On Wed, 3 Oct 2007, Frans Pop wrote:
>
> > The only change is in 2 consecutive columns: "2911 502" -> "2912 500".
> > Is processor usage calculated from those? Can someone explain how?
>
> The latter seems to be utime ...decreasing. No wonder if arithme
On Wed, 3 Oct 2007, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > Try to capture the i/o log with the following command:
> > strace -o top.log top
>
> Thanks for the suggestion.
>
> > This will show for sure whether the kernel gives out incorrect data or
> > top misinterprets t
On Wednesday 03 October 2007, you wrote:
> Try to capture the i/o log with the following command:
> strace -o top.log top
Thanks for the suggestion.
> This will show for sure whether the kernel gives out incorrect data or
> top misinterprets them.
PID USER PR NI VIRT RES SHR S %CPU %ME
Frans Pop wrote:
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The "cc1" is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't ru
On Oct 3 2007 14:33, Frans Pop wrote:
>
>I saw top occasionally displaying % CPU usage for a process. The
>first few times it was amarokapp, this last time it was kontact.
>Both applications were basically idle.
Yes this certainly sounds like KDE. Did you try with Gnome,
or perhaps a simple `
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The "cc1" is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't run top that
frequent
34 matches
Mail list logo
