Message-ID: <56D9F45C.5050602@windriver.com>
Date: Fri, 4 Mar 2016 14:47:24 -0600
From: Chris Friesen <chris.friesen@windriver.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: lkml <linux-kernel@vger.kernel.org>,
        Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: question about logic of steal_account_process_tick() ?
References: <56D9E72D.5060308@windriver.com>
In-Reply-To: <56D9E72D.5060308@windriver.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 854
Lines: 19

On 03/04/2016 01:51 PM, Chris Friesen wrote:

> The thing is, steal_account_process_tick() returns units of cputime, which I
> think is nanoseconds on x86_64.  So if we have a tiny amount of stolen time it
> seems like that will prevent a whole tick from being accounted into
> user/system/idle.
>
> I feel like I must be missing something here, can someone tell me what it is?

Looking at commit dee08a72 (from 2014) it seems like the units of the return 
value of steal_account_process_tick() changed from ticks to cputime_t.  I don't 
see an equivalent change in the logic in account_process_tick(), which seems to 
assume that a nonzero return value in steal_account_process_tick() means a whole 
tick has been stolen.

Was there a change to make paravirt_steal_clock() increment in ticks?  If not it 
seems like there's a unit mismatch here.

Chris