From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [PATCH] remove blocked time accounting from xen "clockchip" Date: Wed, 09 Nov 2011 18:47:26 +0100 Message-ID: <4EBABCAE.40704@redhat.com> References: <1318970579-6282-1-git-send-email-lersek@redhat.com> <4EBA8FAA020000780005FD5F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------090702040602050905030609" Return-path: In-Reply-To: <4EBA8FAA020000780005FD5F@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Joe Jin , Zhenzhong Duan , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------090702040602050905030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/09/11 14:35, Jan Beulich wrote: >>>> On 18.10.11 at 22:42, Laszlo Ersek wrote: >> ... because the "clock_event_device framework" already accounts for idle >> time through the "event_handler" function pointer in >> xen_timer_interrupt(). >> >> The patch is intended as the completion of [1]. It should fix the double >> idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to >> stolen time accounting (the removed code seems to be isolated). > > After some more looking around I still think it's incorrect, albeit for > a different reason: What tick_nohz_restart_sched_tick() accounts > as idle time is *all* time that passed while in cpu_idle(). What gets > accounted in do_stolen_accounting() (without your patch) is > different: > - time the vCPU was in RUNSTATE_blocked gets accounted as idle > - time the vCPU was in RUNSTATE_runnable and RUNSTATE_offline > gets accounted as stolen. > > That is, on an overcommitted system (and without your patch) I > would expect you to not see the (full) double idle increment for a not > fully idle and not fully loaded vCPU. I tried to verify this with an experiment. Please examine if the experiment is bogus or not. On a four-PCPU host (hyperthreading off, RHEL-5.7+ hypervisor & dom0) I started three virtual machines: VM1: four VCPUs, four processes running a busy loop each, independently. VM2: ditto VM3: single VCPU running the attached program (which otherwise puts 1/2 load on a single CPU, virtual or physical.) OS is RHEL-6.1. In VM3, I also ran this script: $ grep cpu0 /proc/stat; sleep 20; grep cpu0 /proc/stat cpu0 10421 0 510 119943 608 0 1 122 0 cpu0 11420 0 510 121942 608 0 1 126 0 The difference in the fourth numerical column is still 1999, even though only 10 seconds of those 20 were spent idly. Does the experiment miss the point (or do I), or does this disprove the idea? (Interestingly, according to virt-manager, the load distribution between the VMs looked like: VM1: 7/16 = 43.75% VM2: 7/16 = 43.75% VM3: 2/16 = 1/8 = 12.50% as if VM3's load had been first extracted and the rest split between VM1 and VM2. When I stop VM1 and VM2, VM3 stays at 12.5%. Under the above load, I would have expected: VM1: 8/17 ~= 47.06% VM2: 8/17 ~= 47.06% VM3: 1/17 ~= 5.88% ie. "eight and half" VCPUs sharing the host evenly. Could this have any relevance?) Thank you Laszlo --------------090702040602050905030609 Content-Type: text/plain; name="50.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="50.c" #define _XOPEN_SOURCE 500 /* SUSv2 */ #include /* sigaction() */ #include /* setitimer() */ #include /* assert() */ #include /* pause() */ static volatile sig_atomic_t flag; static void ring(int sig) { flag = !flag; } int main(void) { struct sigaction act; int tmp; struct itimerval itmv; act.sa_handler = ˚ tmp = sigemptyset(&act.sa_mask); assert(0 == tmp); act.sa_flags = 0; tmp = sigaction(SIGALRM, &act, 0); assert(0 == tmp); itmv.it_value.tv_sec = itmv.it_interval.tv_sec = 0; itmv.it_value.tv_usec = itmv.it_interval.tv_usec = 100 * 1000; tmp = setitimer(ITIMER_REAL, &itmv, 0); assert(0 == tmp); for (;;) { while (0 == flag) ; (void)pause(); } } --------------090702040602050905030609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------090702040602050905030609--