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 DB821C433E0 for ; Sat, 13 Jun 2020 06:22:59 +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 A890420739 for ; Sat, 13 Jun 2020 06:22:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A890420739 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 1jjzYe-0005c6-1z; Sat, 13 Jun 2020 06:22:24 +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 1jjzYc-0005c1-Gt for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 06:22:22 +0000 X-Inumbo-ID: 3bf41e5d-ad3e-11ea-b638-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3bf41e5d-ad3e-11ea-b638-12813bfff9fa; Sat, 13 Jun 2020 06:22:20 +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 5B10CAE25; Sat, 13 Jun 2020 06:22:22 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk , "dfaggioli@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" 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> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Sat, 13 Jun 2020 08:22:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" 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. Juergen