From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 494FF6EB7D for ; Tue, 31 Dec 2024 07:32:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735630383; cv=none; b=tJAgL5uMOtAnOFbXfki2HxMecy5xGDlKxn1S/OIiAUWupVbdyQ+sd025an3f7ge9CTj+mA2+VWmczYoxypX5JgbJSXRSLoQ/l/FYvvrtX1pVqltg+R5xuq6HPCEzVEMe5os06qs7pNBpJ/LmA8Yv9YVsbMAVUl9D8zpvagpHrQw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735630383; c=relaxed/simple; bh=knGnBrvlJpZBtUycXV4CMSJFXFExxHOaDqsyg+Uu8U8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=avQmYouWudwajogj9rBcbw9LPbdz0vqqC192DnV/Aj/7ivkLYrkI2JwFHeyanQ0Z30pqEldAP9kpPjZTlvhQsnnjdXgaIk2anvtIcUY7JZ6WB2+yl3927ZbfeJsoq5WKvOULzDj9GlSbFX9HiqRVE7HC9M7RFngFyZnVcMj5B1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=gK1Xb32S; arc=none smtp.client-ip=209.85.222.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="gK1Xb32S" Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-7b8618be68bso766048785a.3 for ; Mon, 30 Dec 2024 23:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1735630379; x=1736235179; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8GdCZ2+3WfpH4K7/PaKyBk2I+NRHqlahYd4+UosuTIA=; b=gK1Xb32SJUI576f50f8B4P3pZNJr6yxEiUAI8ajHb/e/9SrqUIE60Etfinh2zwxnpN +rjFf6SjxDEngIJHyCKYgvLSPhZrpIksmeIDOGZQFDUOZxSHwhxFqG4L810YtuPTVP0K 5kWXpGVM8Kn6GPMSJ48+G72+crxthSVCHWQOZNQQYkXn3OMRcWwpqIrKqGCXz1bCZKHP T7GLjxKTlDclk/427uBfbtkhQE3MQVQarKx70l80+m0UV7r1BVtU0o9yk2K9DqJXhmrC eU5mtkhWGK7SuXVEJUOWKRPBuzANcQVGmRXhqiVqAmHGxo1wPvlfF4Rh4c4+ljmMRTJA bz4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735630379; x=1736235179; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8GdCZ2+3WfpH4K7/PaKyBk2I+NRHqlahYd4+UosuTIA=; b=J8HymLKYHMK9d1cuxmAp9TjvFjsNQ+UEdh7TNzz20c5NABb8kJpzW3ShtgZMvw/jPC Q5qdexhyUjwmXNjwE1cTCGu9DjjkkhSGsyFarTTfYDp1jEL8DiOdBlUd+n98qNE/Xt3Z hVqWaHMk8L3sagbkrPR+g4xefaYKFqUNUZNtQXHDbyrsqKSX+UAf7BXj8+umHLmhwcnq w02Wdy1vyFLcXZTISI4IhDJJ8hM5f4NyLmLGdTIg3E1aWYyYjBZmXl07jf3a3P1bllNz 4wbXhck2jAQsvhj6Q2aktpotbbfFF64zEbAEcN6d6BY+3S6xqgRVz3o7IRz7gUi92zDz 2O3w== X-Forwarded-Encrypted: i=1; AJvYcCUNPl3FmtQ+3dtMEcidNUfoS3KPSEXI+PzT3m427tYIjQXeYVhiSPV4fVOJ/W9ePOFRF8qjfoRIA/K0JH8=@vger.kernel.org X-Gm-Message-State: AOJu0YxLm4OFivZWCHbXZzgpPjS+OkXPUPkiYPx81dlmeYqOkaXnI2+R 4v2UfnCMqCntAQ5NFci2VVDWhXWl0ZuWLQGvvZkWI9GuGGwdK+gPt5cEypuVwaE= X-Gm-Gg: ASbGncuId7RQoHNAIn4FM+cKQIbsio7HpIOlzu5RZCzemdUBpGFhgbgBdKDEAbqIU+5 VCw6LVvRgjy1Dqrt1LMfpIc5AIIxhAgx+7GMQHhJs+HXcpkamftR1D5ok8e7xUrsdodhbdQX/6b br7H4aHvZqEtjD/p8vBfCAkSMUiZznEFiVES3qcujM/Jzjr/WR59lAcA3TyB+l+EgWirjONR7nF zp77vyiW0+yz79UnKZkMGpQFs200EyS6OtTxHEXKAtDMUGnCjnDDWvmHrB1B+Grx06VOnNWHk+Q CCspj2ERMR+eayLj58abvMF7t4LVWStkhUqTw+k= X-Google-Smtp-Source: AGHT+IGKzFSQnlgEVQ7W9fzOdt8YoCw/kHV5wnhl3R8BviW+UeBxsY+IExYXvcAWzL0EG/6iyEmOrg== X-Received: by 2002:a05:620a:4493:b0:7b6:de3e:1831 with SMTP id af79cd13be357-7b9ba6fdcc6mr4897776885a.9.1735630379039; Mon, 30 Dec 2024 23:32:59 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-46a3e6a1283sm112843631cf.40.2024.12.30.23.32.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 23:32:58 -0800 (PST) Date: Tue, 31 Dec 2024 02:32:55 -0500 From: Gregory Price To: "Huang, Ying" 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. Message-ID: References: <20241210213744.2968-1-gourry@gourry.net> <87o715r4vn.fsf@DESKTOP-5N7EMDA> <87wmfsi47b.fsf@DESKTOP-5N7EMDA> <87v7v5g99x.fsf@DESKTOP-5N7EMDA> 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=us-ascii Content-Disposition: inline In-Reply-To: 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 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. 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. --- 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; }