Re: [PATCH 0/4] cputime: Virtual cputime accounting small cleanups and consolidation

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Jun 21, 2012 at 02:04:24PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-06-21 at 09:58 +0200, Martin Schwidefsky wrote:
> > On Thu, 21 Jun 2012 02:46:29 +0200
> > Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > 
> > > 2012/6/21 Peter Zijlstra <peterz@infradead.org>:
> > > > On Tue, 2012-06-19 at 15:43 +0200, Frederic Weisbecker wrote:
> > > >>
> > > >> I wish we could do more vtime cputime accounting consolidation
> > > >> but archs do the things pretty differently although I bet the
> > > >> behaviour could be more unified.
> > > >>
> > > > Yes.. so s390,ia64 use thread_info, ppc uses their paca (arch private
> > > > precursor to per-cpu data).
> > 
> > s390 uses the prefix page / lowcore to accumulate some accounting information.
> > Which basically is per-cpu data with the advantage that it is accessible with
> > at address 0-8191 for each cpu. The entry code does not have to load a pointer
> > to get to that page, I would prefer NOT to use per-cpu data here.
> 
> Yeah, same for ppc and their paca, I just meant to put the data in
> per-cpu (your lowcore and ppc's paca qualify) storage instead of
> per-task.
> 
> But seeing as I completely overlooked the per-task accounting this
> doesn't matter anyway.
> 
> There being the per-task accounting also completely wrecks the proposal
> I outlined. That only works if its only per-cpu accounting.
> 
> The alternative is going full 64bit ns and having the tick fallback do
> TICK_NSEC increments. 32bit args that don't do VIRT_TIME or IRQ_TIME
> won't like that though :/
> 
> So yeah, I did miss something obvious.. no cookies for me.

Yeah but the idea of a dynamic switching between tick based accounting
and virtual based one (account_system_vtime()) is still valuable to me.

That of course only makes sense if the arch uses some kind of "on-demand"
virtual accounting. Like using TIF flags for syscall slow path and jump
labels for exception hooks. Although in the longer term we should rather
hook on the syscall fastpath, but you get the idea.

How does that sound?

Another way would be to make the adaptive tickless thing depend on
the traditional CONFIG_VIRT_CPU_TIME. So it's simply enabled all the
time and we don't care. But we need syscalls/exceptions hooks for RCU
anyway, which is why I think an on-demand thing could make sense because
both RCU and vtime could use these on-demand hooks.