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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 92B71C433DF for ; Thu, 18 Jun 2020 15:23:35 +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 6A2BA2075E for ; Thu, 18 Jun 2020 15:23:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A2BA2075E 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 1jlwNo-0006lg-8v; Thu, 18 Jun 2020 15:23:16 +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 1jlwNm-0006lb-IQ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:23:14 +0000 X-Inumbo-ID: a012be38-b177-11ea-baac-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a012be38-b177-11ea-baac-12813bfff9fa; Thu, 18 Jun 2020 15:23:13 +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 D95ABAAC7; Thu, 18 Jun 2020 15:23:11 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Julien Grall , Volodymyr Babchuk References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> <87tuz92i6y.fsf@epam.com> <8b87612e-52e3-8f75-27a9-557ed9e7991f@xen.org> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 17:23:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <8b87612e-52e3-8f75-27a9-557ed9e7991f@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 17:17, Julien Grall wrote: > > > On 18/06/2020 03:58, Volodymyr Babchuk wrote: >> >> Hi Jürgen, >> >> Jürgen Groß writes: >> >>> On 13.06.20 00:27, Volodymyr Babchuk wrote: >>>> On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote: >>>>> On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote: >>>>>> On 12.06.20 14:29, Julien Grall wrote: >>>>>>> On 12/06/2020 05:57, Jürgen Groß wrote: >>>>>>>> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>>>>>>>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >>>>>>>>> sched_unit *u) >>>>>>>>> break; >>>>>>>>> } >>>>>>>>> + spin_lock_irqsave(&sched_stat_lock, flags); >>>>>>>>> + sched_stat_irq_time += irq; >>>>>>>>> + sched_stat_hyp_time += hyp; >>>>>>>>> + spin_unlock_irqrestore(&sched_stat_lock, flags); >>>>>>>> >>>>>>>> Please don't use a lock. Just use add_sized() instead which will >>>>>>>> add >>>>>>>> atomically. >>>>>>> >>>>>>> If we expect sched_get_time_correction to be called concurrently >>>>>>> then we >>>>>>> would need to introduce atomic64_t or a spin lock. >>>>>> >>>>>> Or we could use percpu variables and add the cpu values up when >>>>>> fetching the values. >>>>>> >>>>> Yes, either percpu or atomic looks much better than locking, to me, for >>>>> this. >>>> >>>> Looks like we going to have atomic64_t after all. So, I'll prefer to to >>>> use atomics there. >>> >>> Performance would be better using percpu variables, as those would avoid >>> the cacheline moved between cpus a lot. >> >> I see. But don't we need locking in this case? I can see scenario, when >> one pCPU updates own counters while another pCPU is reading them. >> >> IIRC, ARMv8 guarantees that 64 bit read of aligned data would be >> consistent. "Consistent" in the sense that, for example, we would not >> see lower 32 bits of the new value and upper 32 bits of the old value. > > That's right. Although this would be valid so long you use {read, > write}_atomic(). > >> >> I can't say for sure about ARMv7 and about x86. > ARMv7 with LPAE support will guarantee 64-bit atomicity when using > strd/ldrd as long as the alignment is correct. LPAE is mandatory when > supporting HYP mode, so you can safely assume this will work. > > 64-bit on x86 is also guaranteed to be atomic when using write_atomic(). ... and when again the data is suitably aligned, or at the very least (for WB RAM) doesn't cross certain boundaries. Jan