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 5A0067462 for ; Thu, 2 Jan 2025 02:58:52 +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=1735786736; cv=none; b=L7C7Qd4b/mr4ytkR9npFowr6emYJ8ThLpGzJtgQeAZZqbLSb5Yq7wMcKg0/yT4UOdxD3HKPodfGxHIK4FZWUYYEclz1ecT981BYAHMLu/Lzm7FsAVKHE0ddz77rXCmMD8wrTH5zXjy1TkrylG0dyygLz+HlLm3jKhWHmWIygYOk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735786736; c=relaxed/simple; bh=gKVBRyvRQZ6irQ/NGuf2KBwqqeeGHhrQJIwgWOJEf2E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DYrfNNmSvKo8/NucrlU78TDitReFj4FlB3EIxItHa113bvACdbXgdVhFKY0HSavRuOAncV9Rau6NxC1NsMh1V8dcZzvS31SOStFcsjW+JlVBqNoKqntaFT2jATlCk0izWARUdtO2HGgk2lqsQB9knbz1EjYB3H+AZN+5EXbecfA= 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=dD6loOqY; 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="dD6loOqY" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1735786724; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=6Yh6vf8+ethHojYy3krdcXOephCjMdEDw+C6MkIdQ9k=; b=dD6loOqYSj+0TEK77z9FEYPqkiBeWN5zmBNXAJSkX0azDiPyPwUbwQQweqmHh+n6tlAgxKBcN/iX+zTM2Q1l/hYZ98LRquluDS8QKoZEC16BJI/4f+wbnVt7GDRQKWTZDVf+lscfJQsxaXkxz6u5dzyzEQt8K/Yl2bh+b02HI/g= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WMiM1b8_1735786723 cluster:ay36) by smtp.aliyun-inc.com; Thu, 02 Jan 2025 10:58:44 +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 "Tue, 31 Dec 2024 02:32:55 -0500") References: <20241210213744.2968-1-gourry@gourry.net> <87o715r4vn.fsf@DESKTOP-5N7EMDA> <87wmfsi47b.fsf@DESKTOP-5N7EMDA> <87v7v5g99x.fsf@DESKTOP-5N7EMDA> Date: Thu, 02 Jan 2025 10:58:40 +0800 Message-ID: <87ed1lexb3.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 Fri, Dec 27, 2024 at 10:38:45PM -0500, Gregory Price wrote: >> On Fri, Dec 27, 2024 at 02:09:50PM -0500, Gregory Price wrote: >> >> This seems to imply that the overhead we're seeing from read() even >> when filecache is on the remote node isn't actually related to the >> memory speed, but instead likely related to some kind of stale >> metadata in the filesystem or filecache layers. >> >> ~Gregory > > Mystery solved > >> +void promotion_candidate(struct folio *folio) >> +{ > ... snip ... >> + list_add(&folio->lru, promo_list); >> +} > > read(file, length) will do a linear read, and promotion_candidate will > add those pages to the promotion list head resulting into a reversed > promotion order > > so you read [1,2,3,4] folios, you'll promote in [4,3,2,1] order. > > The result of this, on an unloaded system, is essentially that pages end > up in the worst possible configuration for the prefetcher, and therefore > TLB hits. I figured this out because i was seeing the additional ~30% > overhead show up purely in `copy_page_to_iter()` (i.e. copy_to_user). > > Swapping this for list_add_tail results in the following test result: > > initializing > Read loop took 9.41 seconds <- reading from CXL > Read loop took 31.74 seconds <- migration enabled > Read loop took 10.31 seconds This shows that migration causes large disturbing to the workload. This may be not acceptable in real life. Can you check whether promoting rate limit can improve the situation? > Read loop took 7.71 seconds <- migration finished > Read loop took 7.71 seconds > Read loop took 7.70 seconds > Read loop took 7.75 seconds > Read loop took 19.34 seconds <- dropped caches > Read loop took 13.68 seconds <- cache refilling to DRAM > Read loop took 7.37 seconds > Read loop took 7.68 seconds > Read loop took 7.65 seconds <- back to DRAM baseline > > On our CXL devices, we're seeing a 22-27% performance penalty for a file > being hosted entirely out of CXL. When we promote this file out of CXL, > we set a 22-27% performance boost. This is a good number! Thanks! > Probably list_add_tail is right here, but since files *tend to* be read > linearly with `read()` this should *tend toward* optimal. That said, we > can probably make this more reliable by adding batch migration function > `mpol_migrate_misplaced_batch()` which also tries to do bulk allocation > of destination folios. This will also probably save us a bunch of > invalidation overhead. > > I'm also noticing that the migration limit (256mbps) is not being > respected, probably because we're doing 1 folio at a time instead of a > batch. Will probably look at changing promotion_candidate to limit the > number of selected pages to promote per read-call. The migration limit is checked in should_numa_migrate_memory(). You may take a look at that function. > --- > > diff --git a/mm/migrate.c b/mm/migrate.c > index f965814b7d40..99b584f22bcb 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -2675,7 +2675,7 @@ void promotion_candidate(struct folio *folio) > folio_putback_lru(folio); > return; > } > - list_add(&folio->lru, promo_list); > + list_add_tail(&folio->lru, promo_list); > > return; > } [snip] --- Best Regards, Huang, Ying