Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4260390ybp; Mon, 7 Oct 2019 05:56:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyrOLDqczaI11ff/mA7AC50mveQEtzBtqZk8IJuiJt4y5w3H/Y30LCC0shJHx8jx5MKEZfM X-Received: by 2002:a50:a0e2:: with SMTP id 89mr28401122edo.118.1570453016801; Mon, 07 Oct 2019 05:56:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570453016; cv=none; d=google.com; s=arc-20160816; b=X2j0YvzkNAsNBvROdtDV+sVJmEE+kswXLkBd567XXetEnBLMbVo6JZ/D+NOPS3eV5c quGytxnrL71CRsEV+oBLGJDQNlIZMaw6tlupwJmK4HsV2mwYQXYHoRVrnJ6yc7+tqb0y ptNzxsmveJuiYgxwUwRXYY/4pxa5iP22xU/jf+jRZZvN2Y56czM3oxmSrZtPMYxhmIFL Fv187cKql8KDPVAaDV/EYt53fFLMT+mMZBqfXjOyfx0mI3Kus4JQiUludj3hrG8aICOX 7MrkoB4HyCZJXEcOBSqrtmpM1pMoVEtBOT7lBNYSC1al1MYXTFq978nIoO8Eotfci0rP ZkQg== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=h7VZX+XHsEtykLffEVKHOYJRUjKTigVv4CfeaMIzQKM=; b=NqfiF9Q0Km282VK+DNZCEZxDjawctZYtBbXMFomdbaRgTorl7l3iGiXUvsyIoKj7us SmXU2GxIUz7paOJPMfaEF3WlohQbDk7NM3f96N5LyiHHB+4mnIIkjeO/aQ/m2y4eouTr 6u4CIDJrFg91dnIM/H7J4QD0muwZFDzP08MBd7mmFmOUsFq/bJqrQHWkuBodWNeQswju NeBik/BVIe9fgeiyyGX1fPaD3LyZerKi/fsVu9qnmrqCCuvFMm4vaKpmts4CkplnwOBN jTY8umqdLT/H49FM45wk/rcV9x4fMmURflSbQ1BDeL1Vm3sCp/DMLVAiTTzsLBlKORse QRcw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si7119839eju.147.2019.10.07.05.56.33; Mon, 07 Oct 2019 05:56:56 -0700 (PDT) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728371AbfJGMyk (ORCPT + 99 others); Mon, 7 Oct 2019 08:54:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58750 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728354AbfJGMyi (ORCPT ); Mon, 7 Oct 2019 08:54:38 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 468EE3084037; Mon, 7 Oct 2019 12:54:38 +0000 (UTC) Received: from krava.brq.redhat.com (unknown [10.43.17.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A52F5D9CC; Mon, 7 Oct 2019 12:54:35 +0000 (UTC) From: Jiri Olsa To: Arnaldo Carvalho de Melo Cc: lkml , Ingo Molnar , Namhyung Kim , Alexander Shishkin , Peter Zijlstra , Michael Petlan Subject: [PATCH 22/36] libperf: Centralize map refcnt setting Date: Mon, 7 Oct 2019 14:53:30 +0200 Message-Id: <20191007125344.14268-23-jolsa@kernel.org> In-Reply-To: <20191007125344.14268-1-jolsa@kernel.org> References: <20191007125344.14268-1-jolsa@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 07 Oct 2019 12:54:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently when new map is mmaps we set its refcnt to 2 in perf_evlist_mmap_ops::mmap callback. Every mmap is given refcnt set to 2 when it's first mmaped: - 1 for current user, which will be taken out by call to perf_evlist__munmap_filtered, where we find out there's no more data comming from kernel to this mmap - 1 for drain code where in perf_mmap__consume the mmap is released if it is empty Moving this common setup into libperf generic code before mmap callback is called. Link: http://lkml.kernel.org/n/tip-3us74tjjz258bgk2pavjaq59@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/lib/evlist.c | 30 +++++++++++++++--------------- tools/perf/util/mmap.c | 15 --------------- 2 files changed, 15 insertions(+), 30 deletions(-) diff --git a/tools/perf/lib/evlist.c b/tools/perf/lib/evlist.c index b69722627779..f9a802d2ceb5 100644 --- a/tools/perf/lib/evlist.c +++ b/tools/perf/lib/evlist.c @@ -362,21 +362,6 @@ static int perf_evlist__mmap_cb_mmap(struct perf_mmap *map, struct perf_mmap_param *mp, int output, int cpu) { - /* - * The last one will be done at perf_mmap__consume(), so that we - * make sure we don't prevent tools from consuming every last event in - * the ring buffer. - * - * I.e. we can get the POLLHUP meaning that the fd doesn't exist - * anymore, but the last events for it are still in the ring buffer, - * waiting to be consumed. - * - * Tools can chose to ignore this at their own discretion, but the - * evlist layer can't just drop it when filtering events in - * perf_evlist__filter_pollfd(). - */ - refcount_set(&map->refcnt, 2); - return perf_mmap__mmap(map, mp, output, cpu); } @@ -418,6 +403,21 @@ mmap_per_evsel(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops, if (*output == -1) { *output = fd; + /* + * The last one will be done at perf_mmap__consume(), so that we + * make sure we don't prevent tools from consuming every last event in + * the ring buffer. + * + * I.e. we can get the POLLHUP meaning that the fd doesn't exist + * anymore, but the last events for it are still in the ring buffer, + * waiting to be consumed. + * + * Tools can chose to ignore this at their own discretion, but the + * evlist layer can't just drop it when filtering events in + * perf_evlist__filter_pollfd(). + */ + refcount_set(&map->refcnt, 2); + if (ops->mmap(map, mp, *output, evlist_cpu) < 0) return -1; } else { diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c index 2a8bf0ab861c..063d1b93c53d 100644 --- a/tools/perf/util/mmap.c +++ b/tools/perf/util/mmap.c @@ -243,21 +243,6 @@ static void perf_mmap__setup_affinity_mask(struct mmap *map, struct mmap_params int mmap__mmap(struct mmap *map, struct mmap_params *mp, int fd, int cpu) { - /* - * The last one will be done at perf_mmap__consume(), so that we - * make sure we don't prevent tools from consuming every last event in - * the ring buffer. - * - * I.e. we can get the POLLHUP meaning that the fd doesn't exist - * anymore, but the last events for it are still in the ring buffer, - * waiting to be consumed. - * - * Tools can chose to ignore this at their own discretion, but the - * evlist layer can't just drop it when filtering events in - * perf_evlist__filter_pollfd(). - */ - refcount_set(&map->core.refcnt, 2); - if (perf_mmap__mmap(&map->core, &mp->core, fd, cpu)) { pr_debug2("failed to mmap perf event ring buffer, error %d\n", errno); -- 2.21.0