From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6131D2E9F0 for ; Mon, 11 Nov 2024 14:26:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A1C26B007B; Mon, 11 Nov 2024 09:26:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 252496B0083; Mon, 11 Nov 2024 09:26:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 119C46B0085; Mon, 11 Nov 2024 09:26:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E75C46B007B for ; Mon, 11 Nov 2024 09:26:09 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 94409141948 for ; Mon, 11 Nov 2024 14:26:09 +0000 (UTC) X-FDA: 82774038060.04.B9165D1 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf26.hostedemail.com (Postfix) with ESMTP id DA86C140010 for ; Mon, 11 Nov 2024 14:25:36 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=qbyo6QTp; spf=pass (imf26.hostedemail.com: domain of gourry@gourry.net designates 209.85.160.176 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731334976; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C2yryb5aLrrxVSROpkdAf94RmItE+hzldVGe+/Wk7W8=; b=IUCNYQDMeHRwWx6PygOyJ4cW+hhXyXRjALXFwPux2BsmUw1305uL5amEUtUarvnZNcfr+A Fw2ieD8AUT9hTNOHihMpTdXxfAQcb/10agOCzcJWncjXNcoHCToss09Qnh+0nXu6Ve1feU 7OQ34iUAyp+srPYY8tBl3v9MKgJYIzs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=qbyo6QTp; spf=pass (imf26.hostedemail.com: domain of gourry@gourry.net designates 209.85.160.176 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731334976; a=rsa-sha256; cv=none; b=zeJoBXAj12sMpCjLorUnI6GC4q6NfJj3F5mPStZDBFZr8hBQb2hw5750b9GVDE5i/9Cufu lWCbYPr8NZx2GzU7HpNwd5jAQj/kNU/FcNitWtHxtfga+goHPho6esQFyDSQdeJKRTE5tb oboYNn2pxYwRjJc8qFUkVHfWxaOM//I= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-460c316fc37so33866961cf.0 for ; Mon, 11 Nov 2024 06:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1731335166; x=1731939966; darn=kvack.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=C2yryb5aLrrxVSROpkdAf94RmItE+hzldVGe+/Wk7W8=; b=qbyo6QTp3/VTJk6lujKyFpBU5lDWvZQCd0IhQXZKMZE6a2CyGFW6n9Zkszz0NZcALn v38/UZ1eP8E31p5NM1X04xA5Fgez3rIha7qBsXSqs2PjFgDvyQ2eesfNfWTBFFEcoZ21 XAiOalqVmGwzgNUkV0V9xgZTV9QaDiSogeIjPmwtUIdxO0+Ix4HAcbi3tWZdv/lrwyGE FJahH/nP/McT1FWeLOKcH5Go4H5+ORjYLUQbI9FZox6Bqb2vmFZvhIrqRnCKx1eidsK8 XM44X7inG7KsxKfiNN/2ePKgJYNWA5tWZcsniRfCnop52Sec7lrLvgN7Zx3+hj+qdg+s z0+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731335166; x=1731939966; 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=C2yryb5aLrrxVSROpkdAf94RmItE+hzldVGe+/Wk7W8=; b=uWZsyK8T/4YGkpksqWb7VMxfvmnPf3HNrOJQuvfO7pbDF0nHwyJqWovAYZVA3H0T5U nmvMR5BRSYBQ0z7CpAfrtma18Tw1yFd9zUgAI8qUiWmda+Qr63VZiteDlore0iyvTGFr 1CWKB3QzpIsSW+NF3DnYmNvyqu7mJF6qh3teriu+3wqWaH30WjuWD1UAtPx2lBHWWoAp HMjnl2YejrvFjgQc/p+m/+rcbZvQZ43NzdpghHEP3gHXf918/isC4pXRJHhPz7bOQlt7 AB4wdu8TXLvR6f3Ft9u3W0OTHIUuS0c5beu0OTwkA4EmYdcXL4UeCyCu41w01PmTU6VK /2tw== X-Gm-Message-State: AOJu0YxTXUa5HkkEvVRjxPg9jbRfSL0KH6OLccLn2VbSOdCgwrGMg/ug tWduL+cW/gAXeKfgT2qnE+TPtwxOkuwrQXdrP6pBJfxiefJtVFC7GCofkHqQ3Dg= X-Google-Smtp-Source: AGHT+IFPdYEpcKfecpWu0FQOfeCgLNf7UC9dknpW5konBKA13v5oKoN1DYrUxOBelYHyRyIAlmdnpw== X-Received: by 2002:ac8:7dd3:0:b0:461:1c54:5bc9 with SMTP id d75a77b69052e-463094250cfmr169188541cf.51.1731335166583; Mon, 11 Nov 2024 06:26:06 -0800 (PST) Received: from PC2K9PVX.TheFacebook.com (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-462ff41148esm63083251cf.19.2024.11.11.06.26.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2024 06:26:05 -0800 (PST) Date: Mon, 11 Nov 2024 09:25:45 -0500 From: Gregory Price To: "Huang, Ying" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, david@redhat.com, nphamcs@gmail.com, nehagholkar@meta.com, abhishekd@meta.com, Johannes Weiner , Feng Tang Subject: Re: [PATCH 0/3] mm,TPP: Enable promotion of unmapped pagecache Message-ID: References: <20240803094715.23900-1-gourry@gourry.net> <875xrxhs5j.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ikvefswp.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzdi782s.fsf@yhuang6-desk2.ccr.corp.intel.com> <871pzi5z8y.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871pzi5z8y.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DA86C140010 X-Stat-Signature: jbdzfsaj8qgxucc7mykra7hqsd14xg4p X-Rspam-User: X-HE-Tag: 1731335136-773486 X-HE-Meta: U2FsdGVkX191glD+0+vxva6/yaqYib1e4F0/8BL5HUbo6MLFLMC1X6KpcexsCEPROTW78/rQobyKzMad0sElJUAa+tmXtT2DEKYLz+VI78OLRiVIa8dxY7SRY0qQZRl6KHFceIXivWlP16eJryuHE0r9ieDOu4/UuzUVXZ7qamcb0wkIF3h6cdRWj6OTmQnqY2Y78VOlNxXFUQO6NyWEnrBG598ydyxfpnL+R2olOcsZLCTffXK9ZoytQ0X/n3f6fH7tL0kbzRK9yWO22u9WViDn2Z5FvXB5sXZbd1bDFd5CtgQzV9ysGNIkdKU9gjdZ8QY33Qz/QkgZGS/60VOWuzlhoEG3xLNZiw3pk8nnYTExNRYIzCdXbCtKGbgbmc7olUVzNP0W0TqnrrdO3d9P+yS51IpJhaKhrWIPTqwuLgZC7cLTtp99pOUPp3Msb1juDNGu8bE+WV8JWcyOa1vrXgtk2Ffg8RlZwLc7brvxBPYWrkmG1h7V9/06UVT0YcRfhPPeLA3bZEYjP6i1wbPEpTu0J9XCyeXftUmYzC4WSWGmApo8mZzQjVIMxU7joVQ3AgYy0CaPH0vZ2um69XOkieZIoiAFkSjcAQO8ZbL5WN2BCZKJDHd4S1j993VpnvhlAV7aQ/7q5PvISW9L9gR20n8xZOuPamz2BdhfDlkGDrMb5Vw+DKDMAUE6Pn+MV3vqBMzqLSy1mR0bVnEKZ4VUW8y5gsXCMgMmbJW4YmgJJ9qlSBgaLDgvS5KQ5vUIxTNM1+BaA0WiOYEgt7fE+qUICy+WqjIAJbC1v9sFOtUrFORxZ1uZX7RTmzK24d7rOdtF4TKu9hSnIC2TEU0Zbe1WKQWGM3pri+PpktDnkN9E92J3Z2JiPl7aekVeZbQWyXEXlXzUIPq7zEn5CM0+PzHc8k5vVL4AMDqQpXa8rJ45T/cd3GCuPdpx1zx+fRa2AEROyOQhgFGTqfOhsAvtyhG AOpqxCCC UlqZw/IbTDqwPN0wxeilpShX9ioU9J0txTQj1l6gdSWb4hnq265fSZKPf5X+b/WcZ83FXIlQWWGgN1HJNaOrOoiQqDbeb66yFs0uBQiKaUDayh5v0mOylLr/gswsEP1nC7Yw1LmObGfCdf9fGBX7BdqkPjo+AswBwH44Ay3AHqqM+qTh0Y+9oto40yGA/MqJ8Q7H4uIsCbvIqIPSVVSdrm3bNB7JKq0JsuQstXmX2gGWbxRbCNmJQpr5FCij5s9TcLUVWAboe0S02TAhrd1A5hNWQndBhwK4q80puOYCKtYzvz4qecoaF0s/yw5gZX/0Z0oSWOxcjg4+dwJ3s3/KAmNJFLJ2L0t8Extrn X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Nov 11, 2024 at 09:35:09AM +0800, Huang, Ying wrote: > Gregory Price writes: > > > > > Exploring and testing this a little further, I brought this up to current > > folio work in 6.9 and found this solution to be unstable as-is. > > > > After some work to fix lock/reference issues, Johannes pointed out that > > __filemap_get_folio can be called from an atomic context - which means it > > may not be safe to do migrations in this context. > > Sorry, I don't understand this, the above patch changes > filemap_get_pages() and grab_cache_page_write_begin() instead of > __filemap_get_folio(). > on newer kernels, grab_cache_page_write_begin is a compat wrapper for __filemap_get_folio and folio_file_page. This chunk of code has changed somewhat significantly, actually. > > We're back to looking at something like an LRU-esque system, but now we're > > thinking about isolating the folios in folio_mark_accessed into a task-local > > list, and then process the list on resume. > > If necessary, we can use a similar method for above solution too. And > we can filter accessed once folios with folio_mark_accessed() firstly. > That is, only promote a page if, > > - record the folio access time in folio_mark_accessed() only > - when the folio are accessed again, and "access_time - record_time < > threshold", promote the folio. > yes this was the thought. > > Basically we're thinking > > > > 1) hook folio_mark_accessed and use PG_ACTIVE/PG_ACCESSED to determine whether > > the page is a promotion candidate. > > 2) if it is, isolate it from the LRU - which is safe because folio_mark_accessed > > already does this elsewhere, and place it onto current->promo_queue > > 3) set_notify_resume > > 4) add logic to resume_user_mode_work() to run through current->promo_queue and > > either promote the pages accordingly, or do folio_putback_lru on failure. > > Use a task_work? > probably more correct, had a discussion about kernel threads accessing file cache and we weren't sure if that situation even existed - so probably going to try task_work first. ~Gregory