From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.127.231.111 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793955072; b=ZsTQlSse8I5uTTYhHgr6pZeIVdoaS9fRBLIn8sSK9JU6A02WLFbTSZ/jpOwNME68yN5p H4i0V5xTAzdTtmeRZPj25uE0NEUxtzL/Wzvzju2Z4Z/AFVWnI8jJErMqsXO8MMQP2Rzfy evITJZNWX8T7hSmsTVRPSvTVJM53yrENs+YCLa3rRFLVsgIeB64JhS05Qnyf0inBicgdI XjobFo5fqS5aiDSpewujwMBA8S3LK/DMpGqr9z8jpI/SrZeBvjwBzvaWXdf7AbAsCYs5W TNFk3ChaHadLblQ/ulB3t4hnMecCcuWYGeJ0yvBSWQnD/sFqq1o32wIvdnaWy0Ml85A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793955072; h=DMARC-Filter:DKIM-Signature:To:Content-Transfer-Encoding:Subject: Content-Type:X-Original-From:X-Lms-Return-Path:Cc:Date:Message-Id: In-Reply-To:X-Mailer:From:Mime-Version:References; bh=uw2jcbo2K94Ipub2qP4Q99pSQbMkC01ncZoy8NZ7ZtE=; b=Orw4+F3EzWEkO1jmEgp+dhSK0Pq+y9uS1dFjK0HgBuel2oj9DzUYmiLmhF4w5EiNT+9W 5FOz3vkAOh/3esNbTkMYbzyJohHRBK0GMr6nmMBq/MJb44t4oJKUMb0mueQgFh3xqapbj fpITvG0RD4iSRQ+zpKO+xR3d7xnXVP2ppxsjfP7nUVANM/jOrH0SpTzYXbqHvQNGLQ8MX C6QICSVmOar3wGTKnUr+4pzgLAAoOnstxQ0M09Yk41u1cTZ1M9uoARZuHG4TqZuMh9oLY zvT9mSm94/SIx+i65xrDRq0aEDc0Kmu4KNTeQXXrdAj0yjQQG4W4LWDoiJifie148IQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b="PA/XBQAm"; arc=none smtp.remote-ip=209.127.231.111 Received: from va-2-111.ptr.blmpb.com (va-2-111.ptr.blmpb.com [209.127.231.111]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80FBA606A32D for ; Fri, 6 Nov 2026 08:51:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 80FBA606A32D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=PA/XBQAm DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1793955065; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=uw2jcbo2K94Ipub2qP4Q99pSQbMkC01ncZoy8NZ7ZtE=; b=PA/XBQAmEx8IsPS/7OJFQLeZ4Vjk/Xgf6CGt3AkrAKm6p3LefoZj01Twa7vDqugD69JTCX OoLavvqGtxiChoXZtxmsdKYlGIOffsC3eZp2ygVGEhoOVkIQv/V0wdij/ExxrW9gptS4sC huFbds+bdNGUJQ5pscQMUUnTSvwRyhYbmRpMSuoA+T2UFt+TfZJvf67gSlEl3Zn81x+XTK mQqcX7/6ZQthHCYwoS+rLfXUyD2l4P7ZcBA9bUtUSn1hRuYf/bd4ZCUgVcf/YA5GdKe8D1 AI1y+Li+bj7iFxzsRI/E00L2eRhtPBCcqpeBV17nEuyFfspF748Rn6I2/QnlNA== To: Content-Transfer-Encoding: 7bit Subject: Re: [RFC PATCH v3 0/3] mm: use non-temporal stores for demotion Content-Type: text/plain; charset=UTF-8 X-Original-From: Li Zhe X-Lms-Return-Path: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Fri, 6 Nov 2026 16:50:19 +0800 Message-Id: <20261106085019.90487-1-lizhe.67@bytedance.com> In-Reply-To: <20261103223025.2482227-1-nhuhuan@google.com> X-Mailer: git-send-email 2.45.2 From: "Li Zhe" X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 References: <20261103223025.2482227-1-nhuhuan@google.com> On Tue, 3 Nov 2026 14:30:22 -0800, Huan Nguyen wrote: > Using non-temporal stores and prefetching on x86 bypasses CPU cache > allocation, protecting active workload working sets and improving > demotion throughput. Could you show some real workload numbers for this? I am wondering whether the reduced cache allocation and improved demotion throughput also translate into visible application-level benefits. > - Memory ordering: > Add a wmb() barrier at the end of folio_mc_copy_nt() to ensure weakly > ordered non-temporal stores are drained before page tables are updated. I have not looked into all the details here, so I may be missing something. But before migration completes, there should eventually be a publication step that makes the new folio visible. In theory, that publication step should already provide the required ordering before userspace can observe the new folio. So I wonder whether the wmb() in folio_mc_copy_nt() is really needed here. Thanks, Zhe