Jan Beulich
2011-Dec-22 08:49 UTC
Re: [PATCH] remove blocked time accounting from xen "clockchip"
>>> On 21.12.11 at 14:53, Laszlo Ersek <lersek@redhat.com> wrote: > On 12/21/11 09:32, Jan Beulich wrote: >> I currently have no idea what the remain 1% could be attributed to, >> so thoughts from others would certainly be welcome. > > What about irqtime_account_process_tick() calling account_idle_time() > with "cputime_one_jiffy" -- it could more frequently trigger the > underflow in _cputime_to_cputime64(). In that case we might want to > decrease idle time (ie. account "negative" cputime against idle), but can''t.Despite my thinking of this supposedly being impossible, I put in accounting of what is getting lost here. With an unexpected result: There''s far more stolen ticks that can''t get subtracted from one of the other counters than such that can. With the result that if I kept a record of how many still didn''t get used for adjustment, there would then be about 10% under-accounting (instead on the 1% over- accounting). I understand this as meaning that the majority of stolen ticks don''t get mis-accounted in any of the other counters, and it''s just very few that need to be corrected for. But I''m not entirely convinced of this explanation. Jan
Maybe Matching Threads
- Process accounting in interrupt diabled cases
- Process accounting in interrupt diabled cases
- [PATCH] ia64, xen: compilation fix caused by 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d
- [PATCH] ia64, xen: compilation fix caused by 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d
- [PATCH v3 0/4] xen/arm: CONFIG_PARAVIRT and stolen ticks accounting