On Wed, Nov 14, 2018 at 03:45:46AM +0100, Frederic Weisbecker wrote: > Locking the seqcount on idle vtime accounting wasn't thought to be > necessary because the readers of idle cputime don't use vtime (yet). > > Now updating vtime expect the related seqcount to be locked so do it > for locking coherency purposes. > > Also idle cputime updates use vtime, but idle cputime readers use the > traditional ad-hoc nohz time delta. We may want to consider moving > readers to use vtime to consolidate the overall accounting scheme. The > seqcount will be a functional requirement for it. > > Signed-off-by: Frederic Weisbecker <[email protected]> > Cc: Yauheni Kaliuta <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Rik van Riel <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Wanpeng Li <[email protected]> > Cc: Ingo Molnar <[email protected]> > --- > kernel/sched/cputime.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c > index 54eb945..6e74ec2 100644 > --- a/kernel/sched/cputime.c > +++ b/kernel/sched/cputime.c > @@ -800,7 +800,11 @@ EXPORT_SYMBOL_GPL(vtime_guest_exit); > > void vtime_account_idle(struct task_struct *tsk) > { > + struct vtime *vtime = &tsk->vtime; > + > + write_seqcount_begin(&vtime->seqcount); > account_idle_time(get_vtime_delta(&tsk->vtime)); > + write_seqcount_end(&vtime->seqcount); > }
So this makes switching away from idle more expensive ? Also, vtime_account_system() has this fast-path check in there before taking that lock, should we not do the same? Or should it be removed from vtime_account_system() ?
