From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azon11010054.outbound.protection.outlook.com [52.101.56.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2B5F489888 for ; Tue, 4 Aug 2026 05:00:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.56.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785819634; cv=fail; b=pBQ8DCviXturrT8Qc/BOBtajscJGMyGApDmO7K6p7HVVi35NI+quGHJcvBPvV47iXOj2wF0gapP/SyPH+QpEsWZ86X8h7mqO0mVJd/tJ7KlhfTpnkL7lvg8OjY2sZjuGC1nW0fP7PHuLDX0ZjpWnuf2ysnBR8ovZ3+14SRBRIjI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785819634; c=relaxed/simple; bh=fCInZiGeIb6FXHa/Wfu2KcUkN3r91ZVjBeZwrDFb9Uk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=nMsh56Bh1iUWPx7VwvDEjXwWBA2GgPPAvg7IBUW3wWhIXdIVlRw3EL3SOM3Xo6vKuGyRNhm8eAhoHfkC332y0a5xUnSuVQAVfw/9yNpgegQmlCx+Z45/LndXbK4BL7MpLiAKUfWN4oGMVy12EHxH71Cbk/SmJ0OncLmHCDnM3ww= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=1wY2pHrr; arc=fail smtp.client-ip=52.101.56.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="1wY2pHrr" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a+e6mUihOUpZynWqETHNMi3bubgtwM0sfPGrWI3PG1CzryPddkn+4SDeqJ+1dQ4oyMIyBR7VnvihxNPDukjQHO3/PQnrY6PXqHuKJuxsRxho75rasZ2tjRzN5iLZWdEM9/5APrxSncOfrKRQa0rkVymmN0oQvpSqRhcMQYcYSUgKILVmbY3su/OZoObhbB21ja9PJa0MGv4qRnTM8HDDu1CEhv231oAwJuTd5JtodXl58NfRy4dvhoiZZPRyYe6w0Y3pJ+Zs6Gze5qxE1MEi2vHC47jUnHRLlNMTZfYzcbLblZUM53/a+FvaXcv/JvJQ3kjNZre0f+paG0FM8v9xTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A+otf92bSrRHvMRGCAz0NNOcpt8zJ0kpqIyYwaoiDaI=; b=ah7FCcNXxkxL83CTrqMcvnzOT4Lv+kd+ymzfE/7MutfWh6qoF01vljQ95kIXMgc6BWxHwWgNpjs7qv9RDfIsmFbsw4e1eaJRhgaxf6S//puD3OTnDTjf5aX/8inXf/NEvhYrFT79x1khgQHh5jNkjuc45GbvBoGPpbAyw68XpGWcmHAvyeHYQ6bXkTCR7eDFHbAJTkm/H3baUDrd2GOkLHudHi6jS7eeHxKJgHYVBq+2uOxQdoiWmNRXDyBDYGOdZBTCQMV7LFU/AQqPsfFpkFnV++9tXmFAUL2rbV8IPZx9WyeF9pC/aOB/OX3zXFo6Pw3B0XGxt545mmnNya8K+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A+otf92bSrRHvMRGCAz0NNOcpt8zJ0kpqIyYwaoiDaI=; b=1wY2pHrrDAsGvzCW66mrw/+6zjaTr2uVjt7bRG2QtHrRHj0mk9j+heyEyUtVscxzuD5QGN638dRF0o9+ryrMuTLS0aC7eTQRS9/SxUEKHVbbltzCn9kWu74qaxt1ax/oLDob0lwB7pSfEXrUm4ywuFMpFjZ8/hgRFYgrPcFLlHc= Received: from BN1PR12CA0011.namprd12.prod.outlook.com (2603:10b6:408:e1::16) by IA1PR12MB9532.namprd12.prod.outlook.com (2603:10b6:208:595::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.270.18; Tue, 4 Aug 2026 05:00:27 +0000 Received: from BN2PEPF00004FBC.namprd04.prod.outlook.com (2603:10b6:408:e1:cafe::57) by BN1PR12CA0011.outlook.office365.com (2603:10b6:408:e1::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.270.17 via Frontend Transport; Tue, 4 Aug 2026 05:00:27 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF00004FBC.mail.protection.outlook.com (10.167.243.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.8 via Frontend Transport; Tue, 4 Aug 2026 05:00:27 +0000 Received: from satlexmb07.amd.com (10.181.42.216) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Tue, 4 Aug 2026 00:00:20 -0500 Received: from [10.136.47.225] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.41 via Frontend Transport; Tue, 4 Aug 2026 00:00:13 -0500 Message-ID: <7a6aca7d-6c06-4a4b-a404-f0e0a95eae5f@amd.com> Date: Tue, 4 Aug 2026 10:30:12 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 7/8] x86/mm/ibs: In-kernel driver for AMD IBS Memory Profiler To: , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20260728054356.291998-1-bharata@amd.com> <20260728054356.291998-8-bharata@amd.com> Content-Language: en-US From: Bharata B Rao In-Reply-To: <20260728054356.291998-8-bharata@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF00004FBC:EE_|IA1PR12MB9532:EE_ X-MS-Office365-Filtering-Correlation-Id: 0229bf3d-2249-4e12-ec0e-08def1e54d35 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|23010399003|376014|1800799024|7416014|56012099006|10067099003|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: ID0qQ0vhlH4i+5YgdnveWOXIOz6cC0oSeIL/ycBUt5FR4wtdCSf4Z2QsTrvwiB+7r4nYuqD1FoXpStlAcU7gHqciczeNSlj/Vgv0Urb1uw/W7eS1FcWHppO+Nfhmscpos4wsP+oMfStlZ2jkQpVMzJGe7YoExjZ1tHTms47l/vI48Jrq0LE/RLrj85Q86qUQkRXwx/dsIRMceJV4P1dlxisHNshWxBinp9efxHZdoScaBaOn1xjvEOflS2Elo8+/VHs9JNkdY30EOuQcKAdUQTNYPt1NM9ykh6YWTIEayX/QcLp15YhWyMbBMNZbZZfuWxFFwf8PEZzSzWsVMp+/0r15gC9bvXmxtHbGSPJYOI+V3oQLqru6QyZ+jyWVaYcj6CSWHNuJ9g3uLbZ3Wph6vZymT+XcmXWJT3uFQfGyTzjHM0zXduTQ7rbepqOh07UJ2tsW+VK2XfSDm302pK8yBjc/ww/FEcQvXeG0Elpm3VqIltIicV6f2UDbMKYcW3OQNjc4cb9BbZrfxt6KB5QjcL6YL03BeuPoQOrWeapewWZHGi0Yt9/STENGjHyyxWiiQ7myRr99i17CNbaQqVYRs95MYYs7BsKKqxtY7JqJCk3B2i6hwfe0wRAhyonneohOdr/8OaaVcRvywOtBBZ1MD38ZvxjppTvkGZFFxAwIC0vNiWGGmzqlJdo3lNlXsim6vBcRsMCI/dZvR3ukYHsIQw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(36860700016)(23010399003)(376014)(1800799024)(7416014)(56012099006)(10067099003)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EPhz3wm1JxxbXq+zDn6m/VHulIEq6nwRqoFrxN5KCqHvJJ4bDN47BPx61mQJU5TQCpcDaqRCKOWH3MCXI4Cai4F/iRbLiLelSP3EiHdvak4pKgiN4nBUfga+R9ARJi2w3/ZW4/J8OqeOf04JjL9FK7FcDFIayDTD80mafuUI2UMn1GnjEfACUVh9vLq5ZtFNOsg9D2QFyGfQDDYtHVw5epM7nwCho9w9BSEv3+Z8gR0JuQTJ6CTlSwdk4eBA2NGpIHmhPeFGhdTof+cKXaEztlvJTF8k1j7HT2wikAxlJ2/qAYqJvTBC7BJBGjI6WXKDkbfmZrQsgKLwS52ywQuQqxY3xyuxs8xy4otduf91pY0AeI7slqiLu9aFJghQpaRO5odkwrLmHi0hlDo/J3pa8rwBT0Yv/Trg8NyKJqobIvA8ikFUE+Jay5swsLIsTctV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2026 05:00:27.7969 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0229bf3d-2249-4e12-ec0e-08def1e54d35 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BN2PEPF00004FBC.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9532 [Reply to Shashiko review] On 28-Jul-26 11:13 AM, Bharata B Rao wrote: > diff --git a/arch/x86/mm/ibs-mprof.c b/arch/x86/mm/ibs-mprof.c > new file mode 100644 > index 000000000000..923fb8f99552 > --- /dev/null > +++ b/arch/x86/mm/ibs-mprof.c > + > +static bool mprof_pop_sample(struct mprof_sample_pcpu *pcpu, struct mprof_sample *s) > +{ > + int tail = READ_ONCE(pcpu->tail); > + /* > + * Pairs with the smp_store_release() of head in mprof_push_sample(); > + * ensures the sample slot stores are visible before we read the slot. > + */ > + int head = smp_load_acquire(&pcpu->head); > + int next = tail + 1; > + > + if (head == tail) > + return false; > + > + if (next >= IBS_NR_SAMPLES) > + next = 0; > + > + *s = pcpu->samples[tail]; > + > + WRITE_ONCE(pcpu->tail, next); > + return true; > +} > Could the compiler reorder the non-volatile struct assignment of the sample > after the volatile store to tail? > > If a hardware interrupt preempts the worker thread exactly after the tail > update is published but before the sample copy is complete, the interrupt > handler could observe the advanced tail and overwrite the sample data being > read. > > Would it be safer to use smp_store_release(&pcpu->tail, next) here to ensure > memory reads are strictly ordered before the tail update is published? In this sample buffer SPSC ring, there is always one empty slot which keeps the producer at least one slot behind the consumer. So writes to the same slot that is being read is not possible even if the tail update is observed early. Having said that, making the tail publish an explicit release is clearer and symmetric with the head handling. Hence will update this tail publish using smp_store_release(). > +static void mprof_overflow_handler(void) > +{ > + u64 mem_ctl, mem_data3, mem_data2, paddr, data_src; > + struct work_struct *w = &this_cpu_ptr(&mprof_work)->work; > + unsigned long pfn; > + struct page *page; > + > + rdmsrq(MSR_AMD64_IBS_MPROF_CTL, mem_ctl); > + if (!(mem_ctl & IBS_MPROF_CTL_VAL)) > + return; > + > + mprof_disable_profiling(mem_ctl); > + count_vm_event(HWHINT_TOTAL_EVENTS); > + > + rdmsrq(MSR_AMD64_IBS_MPROF_DATA3, mem_data3); > + rdmsrq(MSR_AMD64_IBS_MPROF_DATA2, mem_data2); > + > + data_src = mem_data2 & IBS_MPROF_DATA2_DATASRC_MASK; > + data_src |= ((mem_data2 & IBS_MPROF_DATA2_DATASRC_MASK_HIGH) >> > + IBS_MPROF_DATA2_DATASRC_MASK_HIGH_SHIFT); > + > + switch (data_src) { > + case IBS_MPROF_DATA2_DATASRC_DRAM: > + count_vm_event(HWHINT_DRAM_ACCESSES); > + break; > + case IBS_MPROF_DATA2_DATASRC_EXT_MEM: > + count_vm_event(HWHINT_EXTMEM_ACCESSES); > + break; > + } > + > Does this switch intentionally omit the IBS_MPROF_DATA2_DATASRC_DRAM_FAR case? > It appears that if remote DRAM accesses occur, they are currently silently > dropped from the statistics rather than being counted under > HWHINT_DRAM_ACCESSES. No it was an oversight, remote DRAM access is still a DRAM access. It is just a stats reporting mismatch and promotion behaviour isn't affected. Will include remote DRAM access into HWHINT_DRAM_ACCESSES counter. > + > +static int x86_amd_ibs_mprof_teardown(unsigned int cpu) > +{ > + int offset = get_mprof_lvt_offset(); > + u64 mem_ctl; > + > + if (offset >= 0) > + setup_APIC_eilvt(offset, IBS_MEMPROF_VECTOR, APIC_DELIVERY_MODE_FIXED, 1); > + > + rdmsrq(MSR_AMD64_IBS_MPROF_CTL, mem_ctl); > + mprof_disable_profiling(mem_ctl); > + > + /* > + * The producer is now silenced and this CPU's worker is gone. Drop > + * any unconsumed samples (see mprof_drain_cpu) and clear the pending > + * flag so a subsequent re-online of this CPU starts from a clean > + * state. > + */ > + mprof_drain_cpu(cpu); > + per_cpu(mprof_work_pending, cpu) = false; > + > + return 0; > +} > + > Is the assumption that "this CPU's worker is gone" always true here? > > When a CPU goes offline, its per-CPU workqueues are unbound during the > CPUHP_AP_WORKQUEUE_ONLINE phase, meaning pending work items like > mprof_work_handler can migrate to another CPU and continue executing. > > Because x86_amd_ibs_mprof_teardown runs later in the STARTING phase, > mprof_drain_cpu() modifies the ring buffer unsynchronized. If the migrated > worker is concurrently popping a sample, this could happen: > > Worker CPU (migrated): > mprof_pop_sample() reads tail > > Dying CPU: > mprof_drain_cpu() zeroes head and tail > > Worker CPU (migrated): > mprof_pop_sample() updates tail = next > > Could this desync the tail pointer, potentially causing the worker loop to > read up to 149 uninitialized or stale samples and falsely report them to > pghot_record_access? > > Would it be safer to register the teardown at an ONLINE-level hotplug state > so it can use cancel_work_sync() after disabling profiling? That comment/assumption was inaccurate: after the workqueue unbind at offline, the worker can still be running on another CPU, so mprof_drain_cpu()'s ring reset could race it. The migrated worker operates on its own ring buffer, so it is a single consumer which completely drains the ring on its own. The teardown reset was therefore both redundant and the only thing racing the worker. I will drop it in the next version. Regards, Bharata.