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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 AA03AC55179 for ; Thu, 5 Nov 2020 16:20:07 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 0E6AC20A8B for ; Thu, 5 Nov 2020 16:20:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YDjOHD6A"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BJlNwCmq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E6AC20A8B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=w8Ae6KJG8lLyGlLa+viGBpLTCF+GkjnyDcY1aOiD2Vo=; b=YDjOHD6APST3Y0Uvp0TI/+v9F sWBO/p2M4As8WWqAQPw4iqp9luk0zD8assyH8M+q7o8vzsqZYzWZDVVaobuSux/flMoG8+NZgKzdV SLtjvmsb/Ruo2AkKHKSE/ef930ncIUHh187Eq2DrzhVYhmjaWWx344M8nXwwsFeOgmuS05p+Ao9va 3XpD9WAMxtB8HSoTvQrPlnxZrh8/dKkNy2x9SLttcvlVeaNIDVByw0VKON6NZEwf7LKN4Y7kl4aV+ a5bh58n5lAlEAZnq5GVEwr1mTW66PiNHGqrssLQ6vtFElACpLlC0fEIT+syo3/tJ47Tr2cN3gX1nT S0Aba6rVQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kahz9-0004Ae-UF; Thu, 05 Nov 2020 16:19:39 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kahz7-00049j-CN for linux-arm-kernel@lists.infradead.org; Thu, 05 Nov 2020 16:19:38 +0000 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 323D320A8B for ; Thu, 5 Nov 2020 16:19:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604593176; bh=QFeTsECw8YHTCIMjATwkS4nkIBrexGv1rCsa6+HXtBQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BJlNwCmqauNIFrEDOVlAHNaMc+9T7DtJIKS+0zzIo5AWpGoz8JxyaBpYTYSMxB5VI kk0dZysHwZCk0+AMiCQQsS4paqsS09arfq+DtRHYEO2JQx4hUZxuO7vktRrgsAQhhZ lWmgM1eclGJGYxovgKxpxQ5t/Li+RZLIweKvgfZw= Received: by mail-oi1-f172.google.com with SMTP id d9so2241298oib.3 for ; Thu, 05 Nov 2020 08:19:36 -0800 (PST) X-Gm-Message-State: AOAM530xFS+XSy6/qi4SIPtC7zHFsZbOPvlCQ7hAxZQUv7pRIGXJWIeS Lm2VPVZTZC/PGhbOyPTDpam6bB0WHf9dMklluw== X-Google-Smtp-Source: ABdhPJzJ+6j5XY3vsvevHMD5L1ysbf2vKi4zVY+FZQ91sSdHSgDPKOYyQytGXmWz0fPEZ05QTsQGc01ja5rqku01VBU= X-Received: by 2002:aca:fdd4:: with SMTP id b203mr109871oii.152.1604593175367; Thu, 05 Nov 2020 08:19:35 -0800 (PST) MIME-Version: 1.0 References: <20201001140116.651970-1-robh@kernel.org> <20201001140116.651970-5-robh@kernel.org> <20201014110527.GA1349644@krava> <20201019201541.GN1461394@krava> <20201020153527.GD2113901@krava> <20201021112430.GE2189784@krava> In-Reply-To: <20201021112430.GE2189784@krava> From: Rob Herring Date: Thu, 5 Nov 2020 10:19:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 4/9] libperf: Add libperf_evsel__mmap() To: Jiri Olsa X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201105_111937_590534_2325C822 X-CRM114-Status: GOOD ( 32.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Ian Rogers , Peter Zijlstra , Catalin Marinas , "linux-kernel@vger.kernel.org" , Arnaldo Carvalho de Melo , Alexander Shishkin , Raphael Gault , Ingo Molnar , Honnappa Nagarahalli , Jonathan Cameron , Namhyung Kim , Itaru Kitayama , Will Deacon , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 21, 2020 at 6:24 AM Jiri Olsa wrote: > > On Tue, Oct 20, 2020 at 12:11:47PM -0500, Rob Herring wrote: > > SNIP > > > > > > > > > > > > > The mmapped read will actually fail and then we fallback here. My main > > > > > > concern though is adding more overhead on a feature that's meant to be > > > > > > low overhead (granted, it's not much). Maybe we could add checks on > > > > > > the mmap that we've opened the event with pid == 0 and cpu == -1 (so > > > > > > only 1 FD)? > > > > > > > > > > but then you limit this just for single fd.. having mmap as xyarray > > > > > would not be that bad and perf_evsel__mmap will call perf_mmap__mmap > > > > > for each defined cpu/thread .. so it depends on user how fast this > > > > > will be - how many maps needs to be created/mmaped > > > > > > > > Given userspace access fails for anything other than the calling > > > > thread and all cpus, how would more than 1 mmap be useful here? > > > > > > I'm not sure what you mean by fail in here.. you need mmap for each > > > event fd you want to read from > > > > Yes, but that's one mmap per event (evsel) which is different than per > > cpu/thread. > > right, and you need mmap per fd IIUC > > > > > > in the example below we read stats from all cpus via perf_evsel__read, > > > if we insert this call after perf_evsel__open: > > > > > > perf_evsel__mmap(cpus, NULL); > > > > > > that maps page for each event, then perf_evsel__read > > > could go through the fast code, no? > > > > No, because we're not self-monitoring (pid == 0 and cpu == -1). With > > the following change: > > > > diff --git a/tools/lib/perf/tests/test-evsel.c > > b/tools/lib/perf/tests/test-evsel.c > > index eeca8203d73d..1fca9c121f7c 100644 > > --- a/tools/lib/perf/tests/test-evsel.c > > +++ b/tools/lib/perf/tests/test-evsel.c > > @@ -17,6 +17,7 @@ static int test_stat_cpu(void) > > { > > struct perf_cpu_map *cpus; > > struct perf_evsel *evsel; > > + struct perf_event_mmap_page *pc; > > struct perf_event_attr attr = { > > .type = PERF_TYPE_SOFTWARE, > > .config = PERF_COUNT_SW_CPU_CLOCK, > > @@ -32,6 +33,15 @@ static int test_stat_cpu(void) > > err = perf_evsel__open(evsel, cpus, NULL); > > __T("failed to open evsel", err == 0); > > > > + pc = perf_evsel__mmap(evsel, 0); > > + __T("failed to mmap evsel", pc); > > + > > +#if defined(__i386__) || defined(__x86_64__) || defined(__aarch64__) > > + __T("userspace counter access not supported", pc->cap_user_rdpmc); > > + __T("userspace counter access not enabled", pc->index); > > + __T("userspace counter width not set", pc->pmc_width >= 32); > > +#endif > > I'll need to check, I'm surprised this would depend on the way > you open the event Any more thoughts on this? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel