Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2768776pxa; Tue, 25 Aug 2020 02:44:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxF3bjo1sLl15URoE7Jwi6viJ1VDZng1PkahZTcJm+zDBC8sZCnf2m6JQRrsHqTRf/ScASi X-Received: by 2002:a17:906:a219:: with SMTP id r25mr9864574ejy.201.1598348644937; Tue, 25 Aug 2020 02:44:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598348644; cv=none; d=google.com; s=arc-20160816; b=jNdwvtKoYRYsvr+fFhQ7mFQELnckGJGTI4LVeDr29RO6AbJxoiRSrnt2puY2OCyzNS 1YGUu9oPaK7dMo7FxwRNLnFpOp2cCBBkApmTxdS8shReHdphZ5QpDDHRdwA7mz0WbGU9 vvUgrqx0mXOau9ynEKvBbGATI3IKyFn63//azL6OmV4XRHGIXf7Hed6x1UcA2+SITt5O kAJmPiFA/kr0scfOJkccISVJnHaJ1soBG3kOB9raNN+eQVzB3JR9TFTIiHieYIvprVtJ fJRR2n2dpFV0XAU/r4pPgMpor6EE1cdmmQ4ZxdzE5XH0/wUyyQjEiDb94ebwkLFpywK6 qJ8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=noljkNWGZ1Jo2xgWc/3EKResY7xDBcnXIfNlXbbFlTc=; b=mxlICnLee7xwrleReGpjy8AhdAyoe7NwKWdJtxSBequvWjTNhN+Qs+5hQqXdjejjWk W1BrodyzPmZj/34DtxFqXSUc3EoKZIrigpuYwLGNqyRLtpLR1fdbveZGVCCxEi2onb14 ln+gpamc7NmVgAkblnLiHRm+iefXup+BuqSAlEpJMttKaY8ISynRe2U1gKJleMuX7zIM itwwG5uexJttBxO89hyILHoGrxwuYVBLL48mav5745CHqbpWFDicsiXFVYF6ByWnqIfZ 7lxfv9c0voT+oR1SBcZ26Z3wqfyYxI5Rl2InX8hImbFygGgkRiA/Xy6KLd7rJt1n4Z4I bK8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si785921edt.439.2020.08.25.02.43.40; Tue, 25 Aug 2020 02:44:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729601AbgHYJj6 (ORCPT + 99 others); Tue, 25 Aug 2020 05:39:58 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:50830 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729580AbgHYJjy (ORCPT ); Tue, 25 Aug 2020 05:39:54 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 5BBD735964E97555A088; Tue, 25 Aug 2020 17:39:51 +0800 (CST) Received: from [127.0.0.1] (10.174.177.157) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Tue, 25 Aug 2020 17:39:44 +0800 Subject: Re: [PATCH] genirq/proc: Show percpu irq affinity To: Thomas Gleixner CC: , Shiyuan Hu , Hewenliang , Marc Zyngier References: <87mu2moqvl.fsf@nanos.tec.linutronix.de> From: Yunfeng Ye Message-ID: <9f8b9f2f-b5f9-35c8-ff5e-22b5d0f347bb@huawei.com> Date: Tue, 25 Aug 2020 17:39:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87mu2moqvl.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.157] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/22 19:35, Thomas Gleixner wrote: > On Sat, Aug 22 2020 at 17:33, Yunfeng Ye wrote: >> On 2020/8/13 16:27, Thomas Gleixner wrote: >> For example, the cmdline "irqaffinity=0,1,126,127" on the 128 cores system: >> >> [root@localhost ~]# cat /proc/irq/4/smp_affinity_list >> 0-1,126-127 >> >> The irq 4 is "arch_timer" interrupt, which is a percpu interrupt. >> >> So is it necessary to show the percpu irq affinity correct? > > Yes, it makes sense to do so, but you used the wrong check. The correct > one is: > > irq_settings_is_per_cpu_devid() > > which will not wreckage the output for other per cpu marked interrupts > which never set the percpu_affinity pointer with the obvious > consequences... The pointer would need a NULL check in any case, but it > might be more straight forward to update affinity when percpu_affinity > is initialized. Haven't looked in detail though. > ok, I will send the patch v2, thanks. > Thanks, > > tglx > > . >