From patchwork Mon Apr 10 18:13:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Liang, Kan" X-Patchwork-Id: 81588 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2074214vqo; Mon, 10 Apr 2023 11:25:30 -0700 (PDT) X-Google-Smtp-Source: AKy350ZDTRrU43KdLimpQpu4hxtzQvaLoRg5uAyaaxHLpowAYn2MaQu/kTbDeV2iG+lxFEctiHGX X-Received: by 2002:a05:6a20:cf49:b0:d3:5224:bbc2 with SMTP id hz9-20020a056a20cf4900b000d35224bbc2mr12584422pzb.42.1681151130370; Mon, 10 Apr 2023 11:25:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681151130; cv=none; d=google.com; s=arc-20160816; b=qA6bLOt+JRXjYgJqw8OvbVg8bc4KAyKwo3Z2ZCbQaBJkgMnWcmHj/EqV6twHkTMbIB 4fzWRgx4VDe6Faqb7Agd8uR5MmJje5dxfFQ+abNE1YirdinORjBYW/WX6OaBMFNvnRHb GIeqFR0rCtQXDguK6MSEkzyWWP0Y+Bb0Hbh+Kc2cHHKsaC0eIEA+xJ/Ao/1fP+9CwtF5 eQ33VYoknvGcStHt/54+Q+WjGufLtj7+IITaxyrrWy01393VWWCwZAbia6QqqvPHzqmI xOtl3ww8DHZzEX4N7vD5g5Nk+QeNXq0aSrJc05NII/8mcX4pXVdoAdajDYiOd/+dyNkl zAAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=vPS7FcTMIyQceeNpWXOtIh+rcZpxtMkMW0y7hWfxTyQ=; b=s7qs33NCVi0wgI9FOZqJPKIann3usuK4ookFU7CWi+Z9JYOqa3hGRc85I9WarvXodt BKk/URxjeZHM6AU+wYNU7LjBofyMax+ljl6CfzMSaEM+xeyOfU5SBZngOy75HQJecrwF jEBmz+dPXBQpykcdl5+xK4Aws3LNcqssZR/nVoBDTCO4gSrltz7KAdMnrNUqiU/O7D1R 2WVBd4YwmX8B5BZP7tcHqURXEkU2rY9f1x+amhURl8SpHnpxEBBUvvra2bDcCguYIzFG eKTHCoc8H8LzWrBm2Ua7rNSOv1QuOrOLIxTdxj3u7j7bBytAT0665oy/T3nltcCaycRw /b4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HKr2t8Th; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r189-20020a632bc6000000b004e018302ac3si10993750pgr.612.2023.04.10.11.25.17; Mon, 10 Apr 2023 11:25:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HKr2t8Th; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230141AbjDJSNc (ORCPT + 99 others); Mon, 10 Apr 2023 14:13:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229711AbjDJSNa (ORCPT ); Mon, 10 Apr 2023 14:13:30 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A16FA1BD6 for ; Mon, 10 Apr 2023 11:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681150409; x=1712686409; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=8GBRU9LWaVgQWgbRBjeCeoZvhh7l+d7u9NegbBgbBfw=; b=HKr2t8ThcIrEcda2EmTwnF3aNpZOMShyrPHvCKWXWol3EckIMZBEXmvx iMDMMHVaSnrw8qXASkdmUEWDNUHenwjMIM6WFv5zhFJOxZfzv/FQg4vyb EwTBlPBbC9TvNXvHjUy9JOjU+Cwbkh7a0ZUJuYPTKv8ICCQzm2hB4fw8f sqHXsA1dpWjsCkhGQDTlGIhdy9j1So6ZSCAjLj5pg3qHwl0a5n2qYlWwn tX08NzBJC9828wSAA3bZ4APkJOCT3FtpRH4IJIl9f3FUgBLwvUv8Xu0Sl Ov8kb/q6Gv4s0XewhmzmAzEthSvBhHAc6PHYHmcGewbnmnfnBBo2p6/U3 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="408559380" X-IronPort-AV: E=Sophos;i="5.98,333,1673942400"; d="scan'208";a="408559380" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Apr 2023 11:13:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="799583519" X-IronPort-AV: E=Sophos;i="5.98,333,1673942400"; d="scan'208";a="799583519" Received: from kanliang-dev.jf.intel.com ([10.165.154.102]) by fmsmga002.fm.intel.com with ESMTP; 10 Apr 2023 11:13:28 -0700 From: kan.liang@linux.intel.com To: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org Cc: eranian@google.com, ak@linux.intel.com, Kan Liang Subject: [PATCH V3] perf/x86/intel/ds: Flush the PEBS buffer in PEBS enable Date: Mon, 10 Apr 2023 11:13:09 -0700 Message-Id: <20230410181309.827175-1-kan.liang@linux.intel.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762814727802584293?= X-GMAIL-MSGID: =?utf-8?q?1762814727802584293?= From: Kan Liang Several similar kernel warnings can be triggered, [56605.607840] CPU0 PEBS record size 0, expected 32, config 0 cpuc->record_size=208 when the below commands are running in parallel for a while on SPR. while true; do perf record --no-buildid -a --intr-regs=AX -e cpu/event=0xd0,umask=0x81/pp -c 10003 -o /dev/null ./triad; done & while true; do perf record -o /tmp/out -W -d -e '{ld_blocks.store_forward:period=1000000, MEM_TRANS_RETIRED.LOAD_LATENCY:u:precise=2:ldlat=4}' -c 1037 ./triad; done *The triad program is just the generation of loads/stores. The warnings are triggered when an unexpected PEBS record (with a different config and size) is found. A system-wide PEBS event with the large PEBS config may be enabled during a context switch. Some PEBS records for the system-wide PEBS may be generated while the old task is sched out but the new one hasn't been sched in yet. When the new task is sched in, the cpuc->pebs_record_size may be updated for the per-task PEBS events. So the existing system-wide PEBS records have a different size from the later PEBS records. The PEBS buffer should be flushed right before the hardware is reprogrammed. The new size and threshold should be updated after the old buffer has been flushed. Reported-by: Stephane Eranian Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang --- Changes since V2: - Flush the buffer when the hardware is reprogrammed. https://lore.kernel.org/lkml/1185d81f-71cc-0428-881a-db4f2cbac823@linux.intel.com/ arch/x86/events/intel/ds.c | 39 ++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 3a77f4336df7..4639d4c1e98d 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -1257,20 +1257,18 @@ pebs_update_state(bool needed_cb, struct cpu_hw_events *cpuc, if (x86_pmu.intel_cap.pebs_baseline && add) { u64 pebs_data_cfg; - /* Clear pebs_data_cfg and pebs_record_size for first PEBS. */ - if (cpuc->n_pebs == 1) { + /* Clear pebs_data_cfg for first PEBS. */ + if (cpuc->n_pebs == 1) cpuc->pebs_data_cfg = 0; - cpuc->pebs_record_size = sizeof(struct pebs_basic); - } pebs_data_cfg = pebs_update_adaptive_cfg(event); - /* Update pebs_record_size if new event requires more data. */ - if (pebs_data_cfg & ~cpuc->pebs_data_cfg) { + /* + * Only update the pebs_data_cfg here. The pebs_record_size + * will be updated later when the new pebs_data_cfg takes effect. + */ + if (pebs_data_cfg & ~cpuc->pebs_data_cfg) cpuc->pebs_data_cfg |= pebs_data_cfg; - adaptive_pebs_record_size_update(); - update = true; - } } if (update) @@ -1331,6 +1329,13 @@ static void intel_pmu_pebs_via_pt_enable(struct perf_event *event) wrmsrl(base + idx, value); } +static inline void intel_pmu_drain_large_pebs(struct cpu_hw_events *cpuc) +{ + if (cpuc->n_pebs == cpuc->n_large_pebs && + cpuc->n_pebs != cpuc->n_pebs_via_pt) + intel_pmu_drain_pebs_buffer(); +} + void intel_pmu_pebs_enable(struct perf_event *event) { struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); @@ -1350,6 +1355,18 @@ void intel_pmu_pebs_enable(struct perf_event *event) if (x86_pmu.intel_cap.pebs_baseline) { hwc->config |= ICL_EVENTSEL_ADAPTIVE; if (cpuc->pebs_data_cfg != cpuc->active_pebs_data_cfg) { + /* + * A system-wide PEBS event with the large PEBS + * config may still be enabled when switching the + * context. Some PEBS records for the system-wide + * PEBS may be generated while the old event has + * been scheduled out but the new one hasn't been + * scheduled in. It's not enough to only flush the + * buffer when a PEBS event is disable. + */ + intel_pmu_drain_large_pebs(cpuc); + adaptive_pebs_record_size_update(); + pebs_update_threshold(cpuc); wrmsrl(MSR_PEBS_DATA_CFG, cpuc->pebs_data_cfg); cpuc->active_pebs_data_cfg = cpuc->pebs_data_cfg; } @@ -1396,9 +1413,7 @@ void intel_pmu_pebs_disable(struct perf_event *event) struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); struct hw_perf_event *hwc = &event->hw; - if (cpuc->n_pebs == cpuc->n_large_pebs && - cpuc->n_pebs != cpuc->n_pebs_via_pt) - intel_pmu_drain_pebs_buffer(); + intel_pmu_drain_large_pebs(cpuc); cpuc->pebs_enabled &= ~(1ULL << hwc->idx);