question about logic of steal_account_process_tick() ?

question about logic of steal_account_process_tick() ?

[Chris Friesen]

I'm trying to wrap my head around how steal_account_process_tick() interacts 
with account_process_tick().

Suppose we have CONFIG_VIRT_CPU_ACCOUNTING_GEN=y and CONFIG_NO_HZ_IDLE, with a 
cpu hog on cpu0 to prevent it going idle.

As I understand it, account_process_tick() will be called once per tick to 
decide whether that tick should be allocated against user/system/idle.  However, 
it first calls steal_account_process_tick() and then returns if that returns a 
nonzero value.

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?

Chris

Re: question about logic of steal_account_process_tick() ?

[Chris Friesen]

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