Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751932AbcLFEVC (ORCPT ); Mon, 5 Dec 2016 23:21:02 -0500 Received: from ozlabs.org ([103.22.144.67]:58831 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbcLFEVB (ORCPT ); Mon, 5 Dec 2016 23:21:01 -0500 Date: Tue, 6 Dec 2016 15:20:55 +1100 From: Paul Mackerras To: Frederic Weisbecker Cc: LKML , Tony Luck , Wanpeng Li , Peter Zijlstra , Michael Ellerman , Heiko Carstens , Benjamin Herrenschmidt , Thomas Gleixner , Ingo Molnar , Fenghua Yu , Rik van Riel , Martin Schwidefsky , Stanislaw Gruszka Subject: Re: [PATCH 00/10] vtime: Delay cputime accounting to tick Message-ID: <20161206042055.GB9068@fergus.ozlabs.ibm.com> References: <1480991543-6557-1-git-send-email-fweisbec@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1480991543-6557-1-git-send-email-fweisbec@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1048 Lines: 23 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? Paul.