From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Vivier Subject: Re: [PATCH v2] kvm: Fix accounting of interrupts during guest execution on s390 Date: Thu, 15 Nov 2007 18:08:06 +0100 Message-ID: <1195146486.4704.60.camel@frecb07144> References: <200711141632.37004.borntraeger@de.ibm.com> <200711151510.37076.borntraeger@de.ibm.com> <1195140247.4704.14.camel@frecb07144> <200711151656.44935.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0319579383==" Cc: kvm-devel , Avi Kivity To: Christian Borntraeger Return-path: In-Reply-To: <200711151656.44935.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org --===============0319579383== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xQWrNcQHDtCLmE0Yh2Qy" --=-xQWrNcQHDtCLmE0Yh2Qy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le jeudi 15 novembre 2007 =C3=A0 16:56 +0100, Christian Borntraeger a =C3= =A9crit : > Am Donnerstag, 15. November 2007 schrieb Laurent Vivier: > > If I remember correctly time accounting on s390 is more accurate than o= n > > x86 ? >=20 > Yes. its done during context switches and resolution is microsecond. >=20 > > Because on x86, as we make the kvm_guest_exit() after local_irq_enable(= ) > > we can also have IRQ with PF_VCPU set... and we discussed a lot on > > probability to know if it was good or not. And on x86 it seems good > > because it is already working like that with system and user time (we > > account time to the space where tick appears). > > see http://lkml.org/lkml/2007/10/15/228 >=20 > I am not sure I fully understand your point, can you try to explain? I can try... on x86 interrupts are accounted to guest time if they occur when PF_VCPU is set... and this not a problem because x86 time accounting is not really accurate (and already works like that). So as s390 accounting is working differently, it seems normal to correct the accounted value. To be annoying, it should be clearer to write this like: if ( (p->flags & PF_VCPU) && !(hardirq_count() - hardirq_offset) && !softirq_count() ) { account_guest_time(p, cputime); return; } as we have: #define hardirq_count() (preempt_count() & HARDIRQ_MASK) #define softirq_count() (preempt_count() & SOFTIRQ_MASK) #define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK)) and in account_system_time(): ... if (hardirq_count() - hardirq_offset) cpustat->irq =3D cputime64_add(cpustat->irq, tmp); else if (softirq_count()) cpustat->softirq =3D cputime64_add(cpustat->softirq, tmp); else if (p !=3D rq->idle) { ... So it is easier to understand we don't account this time to guest if we have hard irq or soft irq But I agree with your patch. Laurent > My patch deals with timer ticks (see hardirq_offset). So if a only a tick > comes in after local_irq_enable the time is accounted to guest time as=20 > before. > I made a test on x86_64 with burnP6 inside a kvm machine. top showed 100% > guest time on an otherwise idle host. So the guest accounting itself did > still work. I tried some disk and network stress on the host but I did no= t > manage to bring hardirq+softirq time above 5%, guest time stayed above > 90%. At least my simple testcase did not show a bias towards irq time. >=20 > > Le jeudi 15 novembre 2007 =C3=A0 15:10 +0100, Christian Borntraeger a = =C3=A9crit : > > > Avi pointed out, that my first patch was broken, here is the 2nd try. > > > I tested the patch on s390 with CONFIG_VIRT_CPU_ACCOUNTING and on x86= _64. > > > Seems to work. > > >=20 > > > Currently the scheduler checks for PF_VCPU to decide if this > > > timeslice has to be accounted as guest time. On s390 host=20 > > > interrupts are not disabled during guest execution. This causes > > > theses interrupts to be accounted as guest time if > > > CONFIG_VIRT_CPU_ACCOUNTING is set. > > > Solution is to check if an interrupt triggered account_system_time. > > > As the tick is timer interrupt based, we have to subtract > > > hardirq_offset. > > >=20 > > > Avi, Ingo, Laurent, feedback is welcome. > > >=20 > > > CC: Ingo Molnar > > > CC: Avi Kivity > > > CC: Laurent Vivier > > > Signed-off-by: Christian Borntraeger > > > --- > > > kernel/sched.c | 6 ++---- > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > >=20 > > > Index: kvm/kernel/sched.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- kvm.orig/kernel/sched.c > > > +++ kvm/kernel/sched.c > > > @@ -3395,10 +3395,8 @@ void account_system_time(struct task_str > > > struct rq *rq =3D this_rq(); > > > cputime64_t tmp; > > > =20 > > > - if (p->flags & PF_VCPU) { > > > - account_guest_time(p, cputime); > > > - return; > > > - } > > > + if ((p->flags & PF_VCPU) && (irq_count() - hardirq_offset =3D=3D 0)= ) > > > + return account_guest_time(p, cputime); > > > =20 > > > p->stime =3D cputime_add(p->stime, cputime); --=20 ------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org -------------- "Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke --=-xQWrNcQHDtCLmE0Yh2Qy Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHPHz29Kffa9pFVzwRApIHAJ9n63V0TgrMeS9SRZOj4v4dBMns4ACg2N1g Mo9HlzO2cH7br81TGzAl1bc= =o4wU -----END PGP SIGNATURE----- --=-xQWrNcQHDtCLmE0Yh2Qy-- --===============0319579383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============0319579383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============0319579383==--