Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp49392ybx; Mon, 4 Nov 2019 15:37:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwHOCrlKoGawchb8ZFc2y1RlW0AqeCRmaxkomJ4Fr1JgXXMc1MX7TePzQSWZ2Mqm0wUepzO X-Received: by 2002:a17:906:edd2:: with SMTP id sb18mr8706679ejb.112.1572910626073; Mon, 04 Nov 2019 15:37:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572910626; cv=none; d=google.com; s=arc-20160816; b=at8neioFApGy+jnjPPsurIsqZtye+M7lQbFw+uGSwziMJEPVyqNqp1q2Bi0vRK1k1p HyM9EDw2G1s200oM6BzE/pCI2/tU+xpQIEFoQspN88R7zRiJCuJaULnFQ/Y7gdhF2ocF GsGT49aeYw29iW7To+bWMVDEylE3TqOSXC0DPPyLlidCJXnS7zrVetMVQYffcsTBLDAW 91jlseSKIcMpEL4x1Oyqo8AYXMODIa0Si+id+xDHw5Acljvhmuv7qXP7NjcksvpWTKSq zmHD6ctnu0YMOj0JBEvej89DeufWKxWKhuc9RR86Cylalse7FyLVX3kGnpnzyLo74tCx q3RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=jbcFLWOMZo0KwNew8tbPUX20YylBreVagW7Mk79Q8DA=; b=YmozYWAPI0W3FteThCapTJi/afyYLqcz4a6MZ8NvUOXnqlfenfFB3CBJfeX53xSLfO ftmkao40eNHyg0CpJ0wiuSDctYfpc89bh1BgPdU+tzsVks3tGppD9HC3sHcnl3LuLx9B bPUHYdOOEhWaQHjr3QGH2WpBvocfmHBHya+r0wZRwUOoLDFTlHN5tjU+JkwDUc6Xoojr sETUX6cpp0bjebPyn9hdni1ME+owtp3pauowW1lPAi+NZWkst1Iqv9MIW21URW2KyeOi XnwDhp+Mf0Vod3y2q0DxyB3foIJsHy0RtWjrk5D+7WQdCj6TiIbaCCy+vax3uhhvlepY bE+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@firstfloor.org header.s=mail header.b=Gv07PrwE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6si13179567ejw.226.2019.11.04.15.36.39; Mon, 04 Nov 2019 15:37:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@firstfloor.org header.s=mail header.b=Gv07PrwE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729714AbfKDXf4 (ORCPT + 99 others); Mon, 4 Nov 2019 18:35:56 -0500 Received: from one.firstfloor.org ([193.170.194.197]:32986 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728987AbfKDXf4 (ORCPT ); Mon, 4 Nov 2019 18:35:56 -0500 Received: by one.firstfloor.org (Postfix, from userid 503) id 0A9598685B; Tue, 5 Nov 2019 00:35:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=firstfloor.org; s=mail; t=1572910554; bh=T6WN/3CmGi87L/O4bOPUkr7RqKMi6e4Y71TMqMSUjGs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gv07PrwEP8Bu2dcguFy0qJaw0tfu61iCyH0ODEWGE/472MXW7iU1wY7HxfEYFicOi 38n+lsenDzqx+y4j+AocaFfHQ3b0oCPYf+ltSHW2MikNK+v1U2zLjqFyENCIpceiTe xc8qfyf22FZjDtdBdtsoqfoWYNRtRDO3a88T54wQ= Date: Mon, 4 Nov 2019 15:35:53 -0800 From: Andi Kleen To: Jiri Olsa Cc: Andi Kleen , acme@kernel.org, jolsa@kernel.org, eranian@google.com, linux-kernel@vger.kernel.org, Andi Kleen Subject: Re: [PATCH v3 4/7] perf stat: Use affinity for closing file descriptors Message-ID: <20191104233553.zcjw2u64pggixkka@two.firstfloor.org> References: <20191025181417.10670-1-andi@firstfloor.org> <20191025181417.10670-5-andi@firstfloor.org> <20191030100554.GE20826@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030100554.GE20826@krava> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > - evlist__for_each_entry_reverse(evlist, evsel) > > - evsel__close(evsel); > > + if (affinity__setup(&affinity) < 0) > > + return; > > + cpus = evlist__cpu_iter_start(evlist); > > + cpumap__for_each_cpu (cpus, i, cpu) { > > + affinity__set(&affinity, cpu); > > whats the point of affinity->changed flags when we call > affinity__set unconditionaly? I think we can do without > it, becase we'll always endup calling affinity__set No we don't in the per thread case (without -a) In this case affinity is never set because there is no cpu. I added it just to make the strace look nicer in this case. > > however, it seems superfluous to always allocate those > bitmaps, while we need just the current cpus that we > run on and also that is probably questionable > > could we put 'struct affinity' to 'struct evlist' > and get rid of all affinity__setup/cleanup calls? > (apart from those in evlist__init and evlist__delete) affinity setup/cleanup is essentially push/pop for the affinity state. For setup while it could be in theory moved it would be a bad API because if someone sets up a evlist inside an affinity region it would save the wrong state. For cleanup there's nothing that would call it to reset the affinity. They could be made global, but that's somewhat ugly and might also break with threading. -Andi