All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Nicolas Saenz Julienne <nsaenz@amazon.com>
Cc: jalliste@amazon.co.uk, mhiramat@kernel.org,
	akpm@linux-foundation.org, pmladek@suse.com,
	rdunlap@infradead.org, tsi@tuyoix.net, nphamcs@gmail.com,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, pbonzini@redhat.com, seanjc@google.com,
	paulmck@kernel.org
Subject: Re: [RFC] cputime: Introduce option to force full dynticks accounting on NOHZ & NOHZ_IDLE CPUs
Date: Wed, 13 Mar 2024 00:13:13 +0100	[thread overview]
Message-ID: <ZfDhiakZWIYGSUTl@pavilion.home> (raw)
In-Reply-To: <CZR39LW50A9F.1DWG2FYJ3OZP8@amazon.com>

Le Mon, Mar 11, 2024 at 05:15:26PM +0000, Nicolas Saenz Julienne a écrit :
> Hi Frederic,
> 
> On Mon Feb 19, 2024 at 5:57 PM UTC, Nicolas Saenz Julienne wrote:
> > Under certain extreme conditions, the tick-based cputime accounting may
> > produce inaccurate data. For instance, guest CPU usage is sensitive to
> > interrupts firing right before the tick's expiration. This forces the
> > guest into kernel context, and has that time slice wrongly accounted as
> > system time. This issue is exacerbated if the interrupt source is in
> > sync with the tick, significantly skewing usage metrics towards system
> > time.
> >
> > On CPUs with full dynticks enabled, cputime accounting leverages the
> > context tracking subsystem to measure usage, and isn't susceptible to
> > this sort of race conditions. However, this imposes a bigger overhead,
> > including additional accounting and the extra dyntick tracking during
> > user<->kernel<->guest transitions (RmW + mb).
> >
> > So, in order to get the best of both worlds, introduce a cputime
> > configuration option that allows using the full dynticks accounting
> > scheme on NOHZ & NOHZ_IDLE CPUs, while avoiding the expensive
> > user<->kernel<->guest dyntick transitions.
> >
> > Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
> > Signed-off-by: Jack Allister <jalliste@amazon.co.uk>
> > ---
> 
> Would you be opposed to introducing a config option like this? Any
> alternatives you might have in mind?

I'm not opposed to the idea no. It is not the first time I hear about people
using generic virt Cputime accounting for precise stime/utime measurements on
benchmarks. But let me sit down and have a look at your patch. Once I find
my way through performance regression reports and rcutorture splats anyway...

Thanks!

      reply	other threads:[~2024-03-12 23:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19 17:57 [RFC] cputime: Introduce option to force full dynticks accounting on NOHZ & NOHZ_IDLE CPUs Nicolas Saenz Julienne
2024-02-20 16:18 ` Sean Christopherson
2024-02-20 18:19   ` Nicolas Saenz Julienne
2024-02-21 16:24     ` Sean Christopherson
2024-02-21 17:11       ` Nicolas Saenz Julienne
2024-03-11 17:15 ` Nicolas Saenz Julienne
2024-03-12 23:13   ` Frederic Weisbecker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZfDhiakZWIYGSUTl@pavilion.home \
    --to=frederic@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jalliste@amazon.co.uk \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=nphamcs@gmail.com \
    --cc=nsaenz@amazon.com \
    --cc=paulmck@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=tsi@tuyoix.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.