Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3603127pxb; Mon, 16 Nov 2020 21:04:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJyLz2clD537oDFCEhjehB5leJkUVEvgVRSzwahAUYInt/Mp73JTMXbimEBDbYjBzz4WdFHR X-Received: by 2002:a05:6402:1155:: with SMTP id g21mr18939628edw.53.1605589441085; Mon, 16 Nov 2020 21:04:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605589441; cv=none; d=google.com; s=arc-20160816; b=TQN4ItUssRu49chCSuPI95OFspko+g+1d043xU1PxZVvmidouz9YQTnBPnppwSiyrY 6Xht0eaoxwzT3QPu3hOEY0Q2mbRujLOpTtluNvEtCEmXpF96UI50kn18CwlodBqsdH2n 7PZ0vSoMS63dkum/UsF/Pdc8/6pGj0aM8GqEhj4Q//ktVISHbmenhIck0/w784y4t/bj Tos8QhxrgBwgkYk/oPaeAxhP4PESJPR/H9a8MZXihiJSZhY7raSvN7R4IYNDprFinsWd x7cNLbipRaNJcWPquGGDUbFZcvCnHCSnM5DHjmXTSVX/9u5sahDOf/VFfAqHVGzeQH3r LyfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=D6Qu4LBvzg0KV5uCK88WACJ6tGCBOoR1HGCMw7qp6WQ=; b=MrnDG15don4Mb4OYzaU3mkzX8zFUISyk3cK/9YpJVyG9zavBUq3ntGqF0AQFbbxEp4 QkB0IN4N1Zq2+wkFtKFei4df/eUItDQk9QVSh6c7Ttl5xEGpb/2MucSpBG/tMdAoSGWN TTOFHPuAfKU3YoA37T4SGLZp+E+Lfn33POD5QNQIpc1mZj5t5etNu87B0NUjnVOJG4uD NRawl3F+lQjOQ0gzyDQQdslsu6AbvICqMTMiYRhxR1oW9acmK9u+uCiHIqh1DGUmhrZw oos7P9ObYUkSBxSkkMlCtWnynHYKKwGqGlSNHWlK5Zk93PBNI24FUmnKN8HSqSgpJ0pU UcUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y18si14134429edl.592.2020.11.16.21.03.37; Mon, 16 Nov 2020 21:04:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725978AbgKQFBu (ORCPT + 99 others); Tue, 17 Nov 2020 00:01:50 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:36374 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgKQFBu (ORCPT ); Tue, 17 Nov 2020 00:01:50 -0500 Received: by mail-lf1-f68.google.com with SMTP id f11so28386027lfs.3 for ; Mon, 16 Nov 2020 21:01:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D6Qu4LBvzg0KV5uCK88WACJ6tGCBOoR1HGCMw7qp6WQ=; b=GjD1zuMtoqHO1ziPsds7y1ADtexEBfTRCH8MyjGh8ZI/2BbgIvQpuhr//em49ghvcK P5odvFILEMkw8jHfhqpswPUVwjVEowZ8deEI9eO7LtDnGOYdze1DQNG2u3QEDWHENBgG Zwlp6ZtealByQVBprI/RJmA2ltGnc2wUnCrfF2loOzJcbJFNGIL7TqkJDomsyRWpvild 1AKwySar4RquFZlWYsIgDMkGd9nmbsBH3Xgjg9DXqo97qCqHINioMh5rFEOLzMeJA3og s4zcg2btoDpbzrL/QA+XWIVcfFbs9d7qUUj7DtIS7pxo4C4Exj1jBal8BNssfEfXMwMD fb/w== X-Gm-Message-State: AOAM530NpWJoaCW0GFKONrs/2CeIQuU8VZ3meTqrxKlwpCFKTf+q1Qst dPkca6qqKZ8aXYLmzZJgMYUT1B7NtCMUvdd8AN0= X-Received: by 2002:ac2:5e72:: with SMTP id a18mr929091lfr.220.1605589307873; Mon, 16 Nov 2020 21:01:47 -0800 (PST) MIME-Version: 1.0 References: <20201106212935.28943-1-kan.liang@linux.intel.com> <20201109095235.GC2594@hirez.programming.kicks-ass.net> <20201109110405.GN2651@hirez.programming.kicks-ass.net> <0a1db246-c34a-22a3-160c-3e0c0a38119d@linux.intel.com> <20201111162509.GW2611@hirez.programming.kicks-ass.net> <2dc483f6-7b29-c42b-13a4-4c549d720aa2@linux.intel.com> In-Reply-To: <2dc483f6-7b29-c42b-13a4-4c549d720aa2@linux.intel.com> From: Namhyung Kim Date: Tue, 17 Nov 2020 14:01:36 +0900 Message-ID: Subject: Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events To: "Liang, Kan" Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Stephane Eranian , Ian Rogers , Gabriel Marin , Arnaldo Carvalho de Melo , Jiri Olsa , Andi Kleen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan wrote: > > > > On 11/11/2020 11:25 AM, Peter Zijlstra wrote: > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote: > > > >> - When the large PEBS was introduced (9c964efa4330), the sched_task() should > >> be invoked to flush the PEBS buffer in each context switch. However, The > >> perf_sched_events in account_event() is not updated accordingly. The > >> perf_event_task_sched_* never be invoked for a pure per-CPU context. Only > >> per-task event works. > >> At that time, the perf_pmu_sched_task() is outside of > >> perf_event_context_sched_in/out. It means that perf has to double > >> perf_pmu_disable() for per-task event. > > > >> - The patch 1 tries to fix broken per-CPU events. The CPU context cannot be > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in the > >> sched_cb_list. Yes, the code is very similar to the original codes, but it > >> is actually the new code for per-CPU events. The optimization for per-task > >> events is still kept. > >> For the case, which has both a CPU context and a task context, yes, the > >> __perf_pmu_sched_task() in this patch is not invoked. Because the > >> sched_task() only need to be invoked once in a context switch. The > >> sched_task() will be eventually invoked in the task context. > > > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and > > only set that for large pebs. Are you sure the other users (Intel LBR > > and PowerPC BHRB) don't need it? > > I didn't set it for LBR, because the perf_sched_events is always enabled > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB > for LBR. > > if (has_branch_stack(event)) > inc = true; > > > > > If they indeed do not require the pmu::sched_task() callback for CPU > > events, then I still think the whole perf_sched_cb_{inc,dec}() interface > > No, LBR requires the pmu::sched_task() callback for CPU events. > > Now, The LBR registers have to be reset in sched in even for CPU events. > > To fix the shorter LBR callstack issue for CPU events, we also need to > save/restore LBRs in pmu::sched_task(). > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.liang@linux.intel.com/ > > > is confusing at best. > > > > Can't we do something like this instead? > > > I think the below patch may have two issues. > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well) now. > - We may disable the large PEBS later if not all PEBS events support > large PEBS. The PMU need a way to notify the generic code to decrease > the nr_sched_task. Any updates on this? I've reviewed and tested Kan's patches and they all look good. Maybe we can talk to PPC folks to confirm the BHRB case? Thanks, Namhyung