Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp484123yba; Wed, 15 May 2019 04:59:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqwcTILHDtQkhweviG4TGUr1y9KM/n2nSeNGkfqhCtRL0VQBWgTP8/J9dvA9mJx3BhnIhK9S X-Received: by 2002:a65:5c82:: with SMTP id a2mr44145359pgt.378.1557921575359; Wed, 15 May 2019 04:59:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557921575; cv=none; d=google.com; s=arc-20160816; b=Kn4lFbGh9ScKpZaFXfdhoTae5lNiTGYuqy9EFjhwy03l3gcVHU+aD1QRkzT/GkBk8y mPP+P96qo3FNLc54hhBOsSl2kMtkgbvjQhrffZAAMybAeNp/cORAlYGJmtLZpA6oFdX7 o/TjWumrUDKNuG7CHZhiI2rR3pxzb5TttV6csOkN+IehhCBO4FuYYKGqENAt+4LyXo/d BS9rsBGyaTlLI7oyj5QupFjXPaazp8gRcOXOtS27cQnrKy3jBzl9fulinlacMLYXt68U YVkkDLI8vigFO66IX8N4qxRRMLcOyDIwUdOyLG2cuNTqOeaWuE2q7Wh8mw4OLRtnu4f2 YESQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=kot3EHg+zWajQQmOrf6NWAzjpQRtbs6tZrnI/KG47K4=; b=VEp0Y+Z6yOMlwLWSrr0VmAyOqBE7a0ZZIRZ4UxzdZQkcSZVXpdupbVWMmRbUb4QIDM 2UKHn29vaUQUCKwYnFfqaozKeO7mjXqdRJ/NeGmURyQU5nqFeZX0M7jWo5gMKd6nnI7z +Asj2zBxLzQVxgizOHI542dvQTNMlIkl7jKbniINiN1+X4Zo81uh8PtKoU71KB1IdJRH u3eiGm0esfkChw7K4PY7cSXNWNBSUWGWcNhzx3umQZjMVfujMzuVWIPm6+nuIcWFXZRE KelzeouqMk+JQywu9wkh9IwbfsaDfLJeUdhLSCmsaggxHprFrgF3ERq88lZqxigkn9P2 GRCA== 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 g1si1625164pgq.268.2019.05.15.04.59.20; Wed, 15 May 2019 04:59:35 -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 S1730714AbfEOLRu (ORCPT + 99 others); Wed, 15 May 2019 07:17:50 -0400 Received: from mga02.intel.com ([134.134.136.20]:65294 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727141AbfEOLRq (ORCPT ); Wed, 15 May 2019 07:17:46 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 04:17:46 -0700 X-ExtLoop1: 1 Received: from um.fi.intel.com (HELO localhost) ([10.237.72.63]) by fmsmga004.fm.intel.com with ESMTP; 15 May 2019 04:17:42 -0700 From: Alexander Shishkin To: Peter Zijlstra , mingo@kernel.org Cc: linux-kernel@vger.kernel.org, acme@kernel.org, jolsa@redhat.com, songliubraving@fb.com, eranian@google.com, tglx@linutronix.de, alexey.budankov@linux.intel.com, mark.rutland@arm.com, megha.dey@intel.com, frederic@kernel.org, alexander.shishkin@linux.intel.com Subject: Re: [RFC][PATCH] perf: Rewrite core context handling In-Reply-To: <20181010104559.GO5728@hirez.programming.kicks-ass.net> References: <20181010104559.GO5728@hirez.programming.kicks-ass.net> Date: Wed, 15 May 2019 14:17:42 +0300 Message-ID: <875zqcx8yx.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > + // XXX think about exclusive > + if ((pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE) && group_leader) { > + err = -EBUSY; > + goto err_context; > } This used to be a problem, because group_leader could have caused move_group, which could then potentially violate the exclusive_event_installable() half way through installing siblings onto the new context (gctx -> ctx). But, with the proposed new order, it's the same context (ctx), but different epc, which is not a problem; any potential violations would be caught by if (!exclusive_event_installable(event, ctx)) that preceeds the move_group block. It also makes sense that exclusive_event_installable() looks on ctx->event_list and not epc lists for this exact reason. In retrospect, we can probably also fix this better in the current code like: if (!exclusive_event_installable(event, ctx) || !exclusive_event_installable(event, gctx)) /* do -EBUSY */ and get rid of the above restriction to allow grouping "exclusive" events. Regards, -- Alex