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 8A000D41D43 for ; Tue, 12 Nov 2024 00:36:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 004136B00F0; Mon, 11 Nov 2024 19:36:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF1CF6B00F1; Mon, 11 Nov 2024 19:36:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D928D6B00F2; Mon, 11 Nov 2024 19:36:51 -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 B863E6B00F0 for ; Mon, 11 Nov 2024 19:36:51 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 59454141B7C for ; Tue, 12 Nov 2024 00:36:51 +0000 (UTC) X-FDA: 82775575974.08.7331252 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf29.hostedemail.com (Postfix) with ESMTP id 97DD3120012 for ; Tue, 12 Nov 2024 00:35:52 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Lq9JONyz; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731371681; a=rsa-sha256; cv=none; b=C0cT/UkdXdHOqKcc0OPNg70qGrFKD6wEIJ6YquJ6K4BABQnnUz/FzHGsi7DgScIUWaxs32 Z6WEcHekqPvzUdfR/6Ahf05vdPLrt6oKVPjUwKDPZ6tRumUi5lxIybn+aGbxx5ftBHzgN6 mS+5zgLHuenftioSsNDWvjfEqoEmFt4= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Lq9JONyz; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731371681; 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=Mbpc7YdYawufoG4zSp+8zi6kAJ0gDCXpnfa2UmDOP4E=; b=d8A39hwi7/7rYaTXemZ5ef3PKUSzwsE7icZuOmgHw3n7TUAHXyNFzBigTrUUXwJTMpfEOp MJ5kaJvDpndB18aze+iu+/HBPmCfBJtCmFVF5UgA9ALoxsDu3vvQ7h35eX1cU8TlDv+VWU 0wuYw7H32riA5zjUPV3wzGbe2yBxwYM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1731371808; x=1762907808; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=OtK3htmu/A7y+zFudLiRHDcKnEp8O0Xf+Lvc2oAChp8=; b=Lq9JONyzFkFQIZW+LcDK+4nEOhIL4bBgFMpy+mUpBPCCU0xx0QuyUfBs jPf1gZL2ZeTOE8QIPBg8CB4kOOzJ7A3l/RbLDrtOTIxRcUKR7RR2jUHXE WWCVqTrck/3H8JJoXsKIthVv0ulWhsLuaYMkADLAb/2gO8Fe1JNRELT3I 8rFusjTI9yOzwebOrrLkYcx/joW5Wxm1o/64XxTs37SjppcCB2nOy1BI2 8T5Oztvowbay4bXYJ1TjPzqCrWbenNzZB60O1Z+wmfcOll/IzvDUTqKMy poJgQIpGhHQovVzQTcyCg/xzKmLfN3SyhkSNoSnlrmA/09hYIIfDj4/hF Q==; X-CSE-ConnectionGUID: G7DFX6IGSDKzeDsk2wnkgA== X-CSE-MsgGUID: PeXs22tDTA+k4/otuRfDiQ== X-IronPort-AV: E=McAfee;i="6700,10204,11253"; a="30598172" X-IronPort-AV: E=Sophos;i="6.12,146,1728975600"; d="scan'208";a="30598172" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2024 16:36:46 -0800 X-CSE-ConnectionGUID: Zn7J473BSWWL85Y8h11nhg== X-CSE-MsgGUID: 3X2orW8lQZe2QR7JaJDd9A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,146,1728975600"; d="scan'208";a="87085658" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2024 16:36:44 -0800 From: "Huang, Ying" To: Gregory Price 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 In-Reply-To: (Gregory Price's message of "Mon, 11 Nov 2024 09:25:45 -0500") 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> Date: Tue, 12 Nov 2024 08:33:10 +0800 Message-ID: <87ttcdz3y1.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 97DD3120012 X-Stat-Signature: 57bgugffsiq63hq7x31npzo4rdkm1f8q X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731371752-866290 X-HE-Meta: U2FsdGVkX1/mx4UMBA5WnfkHJcP3g7plMzbpJCcEvzpVI2hUXxuTM3h/kB790obhiKLBWA6/0K9bwXrrQgIez9/L/1N8ZMpbzSG8T+EimqTwUvYkkk/4iT1XFDVNI25XiNjMThgcj77lCgiXMQ8W5tqmygTJvrNIJsMaHYtsJ1Z511JIkqKoYvtfZ33yRnhyq2m5qDCs8VW85t18m1e2otMl3vWCJy2wf6+UDa0iu381jeijAe1gZwqNAjRI/Gqs7LQdFdclhlKhI9bQGNfNEUn3Y1q/W/kjZgQ6iUPUrulSSQxrhBmgu+9hdEYG+INd8rHStZYJbX8P+lxvKJIuIsx3LtXGpQmAXdxP08UnsYariHsvL0+2vfFAi0iEVody/91lefwMBRs4k/vraaTiaB7vRzVEddqoL3q+3nXUeQl1p6IiOmt2EYJs8YXpdWh1IldDdewq+ADGPB7riHa91bg4ZhbOZJXuCT28DjiB9KSTFMwxHUuV70D2x35XYihBVFbaRu/hvWafNqA+v56U6JzxyQxG9725LLRTARRsC+yasr0AjTJtfxlWf8gcMC653NPHUUbwgLQdPIAKPQ5/LebmJNot0JW143++4HiYl2s/PiOoCN392efjZJWEKlh4SeVLmtt0gAnOw1SFXXQg+aryjctlOrrOEWPCF9nl9aNzx+rXD3r31CbWqa7/nwlEkmzDYDSECN8jTkr54e+y6A5bJf3yYuA4Fq04tr7HXnD2o6+dZXc0S8DJxccVgIysfBMR46Dvh2LJPciEWAGZKVk6MyDmsdlPvrlE8T01Rq+x33bVozxfthrtwRH4YLMFVKe2isLsuZv1Df121KBOth+/JwC/qHCeesBbHx6uHJpMvieXu3Z3lrkOyOvZUTHPDesTGPJHFi9p5+FJesCrxzIUYvgHgDNE15F4gRTvBKZT2xW7N8TznfvDqHqxlnW/6uP5NE1BvT8ycrUvufe Fnixfx/k rNRw/9NZwloG9R+aB9oxtZTgaB25kA3h3iez+4CWi4aZEty2THGqJPCnSsQGiLzf7v5nU+v1ol+3BH/5Bkdd7gFnGhk3WqOBVsXe3rVfhDVbOCC36PzBvqU57pU4qQeT3iZ/BqiYgHgL0NF65+/tf1XK8Xqotv1hNZScZ3rUNa61/pgboiSOGrZQRAt83TsaKz+zao0FCZeDOVzIC6wAbQs85pKR9/fDDx9uH 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: Gregory Price writes: > 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 We can ignore kthread when collecting promoting candidates folios. > going to try task_work first. -- Best Regards, Huang, Ying