All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Spencer Candland <spencer@bluehost.com>,
	dmitry.adamushko@gmail.com, mingo@elte.hu,
	linux-kernel@vger.kernel.org
Subject: Re: Still seeing decreasing stime/utime
Date: Tue, 02 Sep 2008 13:06:25 +0530	[thread overview]
Message-ID: <48BCECF9.5060104@linux.vnet.ibm.com> (raw)
In-Reply-To: <1220110327.14894.40.camel@lappy.programming.kicks-ass.net>

Peter Zijlstra wrote:
> On Sat, 2008-08-30 at 19:25 +0530, Balbir Singh wrote:
>> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2008-08-30 13:27:36]:
>>
>>> On Sat, 2008-08-30 at 11:26 +0530, Balbir Singh wrote:
>>>> Spencer Candland wrote:
>>>>>> Here is an experimental patch (I've just compiled and booted a machine
>>>>>> with it, I am unable to reproduce your problem), could you please test
>>>>>> it for me and see if it helps solve the problem
>>>>> Looks like this fixed it.  I have been testing this for the last 16
>>>>> hours and everything is looking good.
>>>>>
>>>> Excellent! Ingo, Peter, do you like the patch? If so, could you please pick it
>>>> up Ingo. I think we should even push the fix to stable releases.
>>> Looks good, except for the issue you yourself earlier raised, a few of
>>> those functions looks too large to be inlined.
>>>
>> Here's the updated revision with task_*time functions moved to sched.c
>> and inlining removed, except for task_gtime(). I've compiled and
>> booted a machine (x86_64) with this patch applied.
>>
>> Reported-by: spencer@bluehost.com
>>
>> Spencer reported a problem where utime and stime were going negative despite
>> the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected
>> reason for the problem is that signal_struct maintains it's own utime and
>> stime (of exited tasks), these are not updated using the new task_utime()
>> routine, hence sig->utime can go backwards and cause the same problem
>> to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
>> fixes the problem
>>
>> TODO: using max(task->prev_utime, derived utime) works for now, but a more
>> generic solution is to implement cputime_max() and use the cputime_gt()
>> function for comparison.
>>
>> Comments?
>>
>> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> 
> Thanks Balbir!
> 
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

Ingo, could you please pick this one.

-- 
	Thanks,
	Balbir

  reply	other threads:[~2008-09-02  7:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <48B5C4C7.8040509@bluehost.com>
     [not found] ` <48B66BCC.8030207@linux.vnet.ibm.com>
     [not found]   ` <48B702FA.8060308@bluehost.com>
     [not found]     ` <20080828224502.GA1540@balbir.in.ibm.com>
     [not found]       ` <48B859C8.5000001@bluehost.com>
     [not found]         ` <48B8E102.5050503@linux.vnet.ibm.com>
     [not found]           ` <1220095656.8426.23.camel@twins>
2008-08-30 13:55             ` Still seeing decreasing stime/utime Balbir Singh
2008-08-30 15:32               ` Peter Zijlstra
2008-09-02  7:36                 ` Balbir Singh [this message]
2008-09-05 16:15                 ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48BCECF9.5060104@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dmitry.adamushko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=spencer@bluehost.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.