From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B746C433DF for ; Fri, 12 Jun 2020 20:09:19 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D659F206D7 for ; Fri, 12 Jun 2020 20:09:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D659F206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpyq-0003nq-HT; Fri, 12 Jun 2020 20:08:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpyo-0003nl-Gf for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 20:08:46 +0000 X-Inumbo-ID: 84ef2c74-ace8-11ea-b60f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 84ef2c74-ace8-11ea-b60f-12813bfff9fa; Fri, 12 Jun 2020 20:08:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B7BFCABE3; Fri, 12 Jun 2020 20:08:47 +0000 (UTC) Message-ID: <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler From: Dario Faggioli To: Julien Grall , Volodymyr Babchuk , "jgross@suse.com" , "xen-devel@lists.xenproject.org" Date: Fri, 12 Jun 2020 22:08:41 +0200 In-Reply-To: <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> Organization: SUSE Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-a9RRqL44kgNEFokXkhUn" User-Agent: Evolution 3.36.3 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=-a9RRqL44kgNEFokXkhUn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-06-12 at 13:21 +0100, Julien Grall wrote: > On 12/06/2020 12:33, Volodymyr Babchuk wrote: > > On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote: > > > > Basically, this value holds time span between calls to > > > > schedule(). This > > > > variable gets zeroed out every time scheduler requests for time > > > > adjustment value. So, it should not depend on total VM run > > > > time. > > > This is assuming that the scheduler will be called. With the NULL > > > scheduler in place, there is a fair chance this may never be > > > called. > > >=20 > Yeah, this is a good point. I mean, I wouldn't be sure about "never", as even there, we'd probably have softirqs, tasklets, etc... And I still have to look at these patches in more details to figure out properly whether they'd help for this. But I'd say that, in general, we should depend of the frequency of the scheduling events as few as possible. Therefore, using 64 bits from the start would be preferrable IMO. > > > So I think using a 64-bit value is likely safer. > >=20 Yep. > > Well, I wanted to use 64-bit value in the first place. But I got > > the > > impression that atomic_t supports only 32-bit values. At least, > > this is > > what I'm seeing in atomic.h > >=20 > > Am I wrong? >=20 > There is no atomic64_t support in Xen yet. It shouldn't be very=20 > difficult to add support for it if you require them. >=20 Cool! That would be much appreciated. :-D Regards --=20 Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere) --=-a9RRqL44kgNEFokXkhUn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl7j4MkACgkQFkJ4iaW4 c+5AZQ//Zei1VtS8e4OqjD3aJm6mfxzS1VVqGut8VzP76PUF56gsqHreChryanVc swlprXxpHd1h7xtmlUzUZCPzWcrtJbFfCpmVQH1iuJ3fL3YpMJevOL+8+2MkUS4S LiewZteqkqPWmbwBTnFkYVxfdX+Lsogme0hv+PRDiePQ2RvzrmVKTo+BFtUVoWnw 5LGWgcUIpcgtC8wVVbTXx4mrHuVRUJcXQBK5b9UZRh7Grwn9TiH19jyMRzaylF3v P30X37UUBHkgfpBgh38XQpka5iOlaCVNcJvAr1UbtjAvCjcdmm5RCujR5nQNlL99 TDE+Br/6teFQpeV8nKv73HII3OFddjXe5Qj68qmBGSBKOdiT0U19mxMq7DbAtSDO wzeFfWGHFins4q4uoZBdO8UJRGbDeCHKFh3I3qgeg3kenBZouZn1H+aJuJps5Su3 89SaN66/OYHj9yDBqThbdE0g2uBRcdgM9tBuOOFH97WDeAtbORBC8nGHEte5vtrG pxPxizZdFyKyQvu/bJDbC7muoPODhilsJd4aF5Qgrn9ST93CGsEASBcH/96TmFki Wc7vAkcd58gALoxm9Nh/658cowUe5OQqy41NAy/2S+gyVswbBmN6tpBXV4H0e0G8 7cXyH9aniT9nvkcIxCDGymtnYyHGhdU/Czt3p317Jb2HaBmrLRM= =McQc -----END PGP SIGNATURE----- --=-a9RRqL44kgNEFokXkhUn--