From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (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 AA9741FB3 for ; Fri, 27 Dec 2024 02:16:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735265809; cv=none; b=sS23RPfelFLN/c3shKZQhjsVjXz04Ipnb9XJQ6NV39XOErPEW+UzEzL/aaGUyrsisc7miAB3WUfk6q9FFTUY/JVJnbDfTRCaHpRL6fOs09VLqc8od8q/OG/paVRTnY0pxnK0hCogBVtaDl5G2WZkOmm2rsNUhIly67k9b8JLSFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735265809; c=relaxed/simple; bh=AcGb1RFKs0bIUd6xcH6hQ+g1Au2i1CVkqse5651QGec=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=io9/qb2H5i49UL1mb3ODvg5IfOQ/dj+KnIFeS3sqiOTE8bw020Kz2SVp2tdOejDUwmFB2+lOjXEZ6BOU10XLl2kegi2HBUI4o9cyyZw789Moen0ITTmUEuMVEbBCqc6yE0xKJXEjnS/Zxff3TztCPrrmr3+LsS20SNqvowYu0Vw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=cF/hwPp3; arc=none smtp.client-ip=115.124.30.113 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="cF/hwPp3" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1735265804; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=4s85B918jL386HalEmDQaG9nvXObcVt3lF2Icu3gthc=; b=cF/hwPp3c7dUPuVBtXKWuPmyxxcN+GRxqg91sgjXVtJvh6PJVID4rjss1RfRx1loM5V/a27W4YeCbiXGe38LSNGSi66l37LogNbUEG94X1sdDes6WoxfHhtILSwpLcRhFoO7PDyj5ZmNC8MPD970vBTj+CwcHCkYYCtMJeKAPQY= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WMJiNpc_1735265802 cluster:ay36) by smtp.aliyun-inc.com; Fri, 27 Dec 2024 10:16:43 +0800 From: "Huang, Ying" To: Gregory Price Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, nehagholkar@meta.com, abhishekd@meta.com, kernel-team@meta.com, david@redhat.com, nphamcs@gmail.com, akpm@linux-foundation.org, hannes@cmpxchg.org, kbusch@meta.com Subject: Re: [RFC v2 PATCH 0/5] Promotion of Unmapped Page Cache Folios. In-Reply-To: (Gregory Price's message of "Sun, 22 Dec 2024 11:22:30 -0500") References: <20241210213744.2968-1-gourry@gourry.net> <87o715r4vn.fsf@DESKTOP-5N7EMDA> <87wmfsi47b.fsf@DESKTOP-5N7EMDA> Date: Fri, 27 Dec 2024 10:16:42 +0800 Message-ID: <87v7v5g99x.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Gregory Price writes: > On Sun, Dec 22, 2024 at 03:09:44PM +0800, Huang, Ying wrote: >> Gregory Price writes: >> > That's 3-6% performance in this contrived case. >> >> This is small too. >> > > Small is relative. 3-6% performance increase across millions of servers > across a year is a non trivial speedup for such a common operation. If we cannot only get 3-6% performance increase in a micro-benchmark, how much can we get from a real life workloads? Anyway, we need to prove the usefulness of the change via data. 3-6% isn't some strong data. Can we measure the largest improvement? For example, run the benchmark with all file pages in DRAM and CXL.mem via numa binding, and compare. >> > Can easily piggyback on that, just wasn't sure if overloading it was >> > an acceptable idea. >> >> It's the recommended setup in the original PMEM promotion >> implementation. Please check commit c959924b0dc5 ("memory tiering: >> adjust hot threshold automatically"). >> >> > Although since that promotion rate limit is also >> > per-task (as far as I know, will need to read into it a bit more) this >> > is probably fine. >> >> It's not per-task. Please read the code, especially >> should_numa_migrate_memory(). > > Oh, then this is already throttled. We call mpol_misplaced which calls > should_numa_migrate_memory. > > There's some duplication of candidate selection logic between > promotion_candidate and should_numa_migrate_memory, but it may be > beneficial to keep it that way. I'll have to look. --- Best Regards, Huang, Ying