All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	Wanpeng Li <wanpeng.li@hotmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>,
	Rik van Riel <riel@redhat.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Stanislaw Gruszka <sgruszka@redhat.com>
Subject: Re: [PATCH 00/10] vtime: Delay cputime accounting to tick
Date: Tue, 6 Dec 2016 15:34:29 +0100	[thread overview]
Message-ID: <20161206143428.GA2507@lerouge> (raw)
In-Reply-To: <20161206042055.GB9068@fergus.ozlabs.ibm.com>

On Tue, Dec 06, 2016 at 03:20:55PM +1100, Paul Mackerras wrote:
> On Tue, Dec 06, 2016 at 03:32:13AM +0100, Frederic Weisbecker wrote:
> > This follows up Martin Schwidefsky's patch which propose to delay
> > cputime accounting to the tick in order to minimize the calls to
> > account_system_time() and alikes as these functions can carry quite some
> > overhead:
> > 
> > 	http://lkml.kernel.org/r/20161121111728.13a0a3db@mschwide
> > 
> > The set includes Martin's patch, rebased on top of tip:sched/core and
> > latest s390 changes, and extends it to the other implementations of
> > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE (powerpc and ia64) along with a few
> > core changes to adapt the whole.
> > 
> > Only built-tested though as I don't have access to any of these archs.
> 
> The patches look reasonable at a quick look.  I assume that to test
> them, we would want to run a guest in an overcommitted system, so as
> to get some steal time.  Do you have any more specific suggestions as
> to what to run as a test?  Just run some benchmark and see if the
> user/system/irq times look reasonable?  Or do you have something more
> quantitative?

So I guess we want to test both correctness and performance.

To check correctness I use two little programs, one that does a userspace
loop:

int main(int argc, char **argv)
{
	while (1);
	return 0;
}


And another that does a kernelspace loop. The latter
is not 100% kernel loop but spends most of its time in
kernel mode.

int main(int argc, char **argv)
{
	void *addr = sbrk(0);

	while (1) {
		brk(addr + 4096);
		brk(addr);
	}
	return 0;
}

Testing idle time just consist in checking the difference between two
cat /proc/stat in a given timelapse for an idle CPU.

For irqs it gets harder. There you just need to check if the numbers are
reasonable.

Now in order to measure performance, I think you need a workload that either
does a lot of guest/host switch or does a lot of IRQs. Maybe just something
that involves networking. Then comparing stime, hardirq and softirq should
show some better nummbers. In order to increase the effect, you can set a very
low HZ value (100?).

Thanks.

  parent reply	other threads:[~2016-12-06 14:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-06  2:32 [PATCH 00/10] vtime: Delay cputime accounting to tick Frederic Weisbecker
2016-12-06  2:32 ` [FIX][PATCH 01/10] powerpc32: Fix stale scaled stime on context switch Frederic Weisbecker
2016-12-06  2:32 ` [FIX][PATCH 02/10] ia64: Fix wrong start cputime assignment on task switch Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 03/10] cputime: Allow accounting system time using cpustat index Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 04/10] cputime: Export account_guest_time Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 05/10] powerpc: Prepare accounting structure for cputime flush on tick Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 06/10] powerpc: Migrate stolen_time field to accounting structure Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 07/10] powerpc/vtime: Accumulate cputime and account only on tick/task switch Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 08/10] ia64: " Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 09/10] s390/cputime: delayed accounting of system time Frederic Weisbecker
2016-12-10  1:48   ` Frederic Weisbecker
2016-12-12 10:27     ` Martin Schwidefsky
2016-12-12 15:02       ` Frederic Weisbecker
2016-12-13 11:13         ` Martin Schwidefsky
2016-12-13 13:21           ` Martin Schwidefsky
2016-12-14  1:44             ` Frederic Weisbecker
2016-12-20 14:13               ` Martin Schwidefsky
2016-12-20 14:30                 ` Frederic Weisbecker
2016-12-13 14:38           ` Frederic Weisbecker
2016-12-06  2:32 ` [PATCH 10/10] vtime: Rename vtime_account_user() to vtime_flush() Frederic Weisbecker
2016-12-06  4:20 ` [PATCH 00/10] vtime: Delay cputime accounting to tick Paul Mackerras
2016-12-06  7:04   ` Martin Schwidefsky
2016-12-06 14:34   ` Frederic Weisbecker [this message]
2016-12-06  8:40 ` Christian Borntraeger

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=20161206143428.GA2507@lerouge \
    --to=fweisbec@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=fenghua.yu@intel.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sgruszka@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=wanpeng.li@hotmail.com \
    /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.