Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1005144imm; Tue, 3 Jul 2018 04:00:42 -0700 (PDT) X-Google-Smtp-Source: AAOMgpckuDhDThNSbNUZtqTM2EB11b2ClY7jjoKEJytgPh1/8xp8CsV5qfTjV6OCGu6SOMwcyZvo X-Received: by 2002:a63:f18:: with SMTP id e24-v6mr8737271pgl.320.1530615642438; Tue, 03 Jul 2018 04:00:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530615642; cv=none; d=google.com; s=arc-20160816; b=snkDuo6NmO+mF+HQSNJFz/sWjIqrf0Rx/5htBwBClcUUMS663PAWW1FTGfZyrRNjz+ je5PTUzs+KPO5bain24T3jAMX25grJnpJvPmkcxNWWiW1Exgrw6YuDXkRfpJRkTizUjB VkZekn0i76dTSo+Er4La535dKJsNtcymjOv2YM2kp1p1F8t0wqnE0YJnNs4wc1zcT7zw qWCmOqedyTAg+TkGInPPH3Ak6al2ED1UrCz/LASre3iPyt6MFEMuz9gg0pZaaTrlPh6C ynNu/x8zvTETMPA1lfpqJC9/aOuwQkcMMa6i8lPDSuqJ39eaUGwwHQ4NVbH4/9gDmbmf +jYA== 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:mail-followup-to :message-id:subject:to:from:date:arc-authentication-results; bh=oFcN1Xcw7khZHfVEKrsZ7O3xYp9HS/zMfwLDc+/GmSE=; b=lNXwTQLj8RTTp5jUMCv0bg8WrKMmSDNrdXtvVxBTiiRXclwY4COuOdmVWD0PJBDIW6 lKrydl3TsfK4AV2laJFbSdeDQexR2BZfZdxQTkGV/60gGsNmUqsBqjXsqGkVpN+FbFqa cs2jjggTi0GJr4eKetr/UOTdMJfectc0cxaFzcAS5oh9e6t9ak/v9/v+DlPPTBtc+Dh8 4xBg2sEZ7Dud4ahcGur8BJxuhJpTDGVxcicbawVflocBbu+jDuPiuzdh740Swp+OTXrb GBKoB2dTBCCs49YwWi5AZ1fExT2DLgEtvSYnsTeQca5mG0dXzsgeQtEI4pd9yGbneAO7 8s8w== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p18-v6si708125pgu.671.2018.07.03.04.00.27; Tue, 03 Jul 2018 04:00:42 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752721AbeGCK6A (ORCPT + 99 others); Tue, 3 Jul 2018 06:58:00 -0400 Received: from mga14.intel.com ([192.55.52.115]:64863 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752197AbeGCK57 (ORCPT ); Tue, 3 Jul 2018 06:57:59 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 03:57:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,303,1526367600"; d="scan'208";a="69263352" Received: from um.fi.intel.com (HELO um) ([10.237.72.212]) by fmsmga001.fm.intel.com with ESMTP; 03 Jul 2018 03:56:55 -0700 Received: from ash by um with local (Exim 4.91) (envelope-from ) id 1faIzM-0003Ul-Qb; Tue, 03 Jul 2018 13:56:52 +0300 Date: Tue, 3 Jul 2018 13:56:52 +0300 From: Alexander Shishkin To: Mathieu Poirier , peterz@infradead.org, acme@kernel.org, mingo@redhat.com, tglx@linutronix.de, alexander.shishkin@linux.intel.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, will.deacon@arm.com, mark.rutland@arm.com, jolsa@redhat.com, namhyung@kernel.org, adrian.hunter@intel.com, ast@kernel.org, gregkh@linuxfoundation.org, hpa@zytor.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 5/6] perf/core: Use ioctl to communicate driver configuration to kernel Message-ID: <20180703105652.psjq5cq4t7o2j6zk@um.fi.intel.com> Mail-Followup-To: Mathieu Poirier , peterz@infradead.org, acme@kernel.org, mingo@redhat.com, tglx@linutronix.de, alexander.shishkin@linux.intel.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, will.deacon@arm.com, mark.rutland@arm.com, jolsa@redhat.com, namhyung@kernel.org, adrian.hunter@intel.com, ast@kernel.org, gregkh@linuxfoundation.org, hpa@zytor.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <1530570810-28929-1-git-send-email-mathieu.poirier@linaro.org> <1530570810-28929-6-git-send-email-mathieu.poirier@linaro.org> <20180703100348.fy43f4fosw3fdc6i@um.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180703100348.fy43f4fosw3fdc6i@um.fi.intel.com> User-Agent: NeoMutt/20180512 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 03, 2018 at 01:03:48PM +0300, Alexander Shishkin wrote: > On Mon, Jul 02, 2018 at 04:33:29PM -0600, Mathieu Poirier wrote: > > +/* > > + * PMU driver configuration works the same way as filter management above, > > + * but without the need to deal with memory mapping. Driver configuration > > + * arrives through the SET_DRV_CONFIG ioctl() where it is validated and applied > > + * to the event. When the PMU is ready it calls perf_event_drv_config_sync() to > > + * bring the configuration information within reach of the PMU. > > Wait a second. The reason why we dance around with the generations of filters > is the locking order of ctx::mutex vs mmap_sem. In an mmap path, where we're > notified about mapping changes, we're called under the latter, and we'd need > to grab the former to update the event configuration. In your case, the > update comes in via perf_ioctl(), where we're already holding the ctx::mutex, > so you can just kick the PMU right there, via an event_function_call() or > perf_event_stop(restart=1). In the latter case, your pmu::start() would just > grab the new configuration. Should also be about 90% less code. :) Also, since it affects the AUX buffer configuration, it is probably a one time ioctl command that you issue before you mmap the buffer. If that's the case, you don't even have to worry about stopping the event, as it shouldn't be running, because without the buffer perf_aux_output_begin() should fail and so should the pmu::add() iirc. Regards, -- Alex