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 B2E7DCDB474 for ; Fri, 20 Oct 2023 03:14:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29BF48D00E7; Thu, 19 Oct 2023 23:14:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24C008D0003; Thu, 19 Oct 2023 23:14:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 162158D00E7; Thu, 19 Oct 2023 23:14:36 -0400 (EDT) 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 07EE08D0003 for ; Thu, 19 Oct 2023 23:14:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CD294A0517 for ; Fri, 20 Oct 2023 03:14:35 +0000 (UTC) X-FDA: 81364372110.21.30E9D29 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by imf25.hostedemail.com (Postfix) with ESMTP id C582EA0012 for ; Fri, 20 Oct 2023 03:14:32 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MdkodZOE; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697771673; 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=7ywAvwbhJr5/vU0AbBbA2bWEKwNnkjoqCzdwXBcHgIc=; b=WwwRts86qXDAJxASppHkLErrs+/XDrAeJDPbjuXBGgds1ccQmfjGN5ovHr3iDBXefbhkoK qG/DlwymkXN0wevXz7oHTvu4X90EOAkJEQm0HC7ijm3b6ngMS4sIS2tE8aeKwqQvgVwnmR +dlIx8pU43uRXKcK/noOCelOtOg4hLY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697771673; a=rsa-sha256; cv=none; b=H9pBBz0TxhBGhc7EUFvbI9g+lMl88SxUJrFuzMitkB1dYYD4H6e4gJ9tk2WsbglQBvr3Tx A7wjVptT/9MpRvwmNeKaWh2dKwBINHID2pgZ4mqwrzGThiY5Dl8gBi1r9HdvMmqlMAYupY mWG/qm5dNv86cdhO6ECNXIFwcpzq/Ks= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MdkodZOE; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697771672; x=1729307672; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=J+9tE2sdyUVhhpIhll2eZHkIf4yz1uC4SXuiNuD7B+s=; b=MdkodZOEdZBwthd8gbIIfXtiFvqlpCCsTA0IOpOqTuC9FU1LVBaqb8wE gMIpl0AtQgvfCCXHG0iA5jyq3PrH3JPPpbg7E5AulPpgPgCtFwihIzcU2 hmclQ66vrC4PQDdKaLp/t/LpAI6xC7N8+AgKoa3MX+RcuraNXM11b5KSA l5U/IXsyW3veCSdYjvcDrlAp9MLEsliJUMljZg5mYTkYcB40y5FGfalfF pFyNekvsgJGvstUFL/tYD45fSlnO+jTOHjwoWtD4ogJ9NJS5gi604lAQZ GRJsM720ZxV1M1RnFQuTzRcWMIN3XsBKIVEKjJhNoribwD3w2lcVzjYAc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10868"; a="452899357" X-IronPort-AV: E=Sophos;i="6.03,238,1694761200"; d="scan'208";a="452899357" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2023 20:14:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10868"; a="1004468457" X-IronPort-AV: E=Sophos;i="6.03,238,1694761200"; d="scan'208";a="1004468457" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2023 20:14:26 -0700 From: "Huang, Ying" To: Ryan Roberts Cc: Andrew Morton , David Hildenbrand , Matthew Wilcox , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , , , Tim Chen Subject: Re: [PATCH v2 2/2] mm: swap: Swap-out small-sized THP without splitting In-Reply-To: <4b351eaa-c2db-408b-9ce2-4b12e3d6b30a@arm.com> (Ryan Roberts's message of "Thu, 19 Oct 2023 15:25:39 +0100") References: <20231017161302.2518826-1-ryan.roberts@arm.com> <20231017161302.2518826-3-ryan.roberts@arm.com> <87r0ls773p.fsf@yhuang6-desk2.ccr.corp.intel.com> <87mswfuppr.fsf@yhuang6-desk2.ccr.corp.intel.com> <4b351eaa-c2db-408b-9ce2-4b12e3d6b30a@arm.com> Date: Fri, 20 Oct 2023 11:12:24 +0800 Message-ID: <87sf66f0mf.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: C582EA0012 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 133buboqtyx5gozp78ma9ndswki9ti99 X-HE-Tag: 1697771672-313297 X-HE-Meta: U2FsdGVkX19X+wMqaXAUaoQsNRBbgu7DE4zy39elD2NalNO+nUc5zlgr3VuCzsPxELSuay2JXHn6NuGxe9D0c+4NypB1RsKsfwCjGjpyI9ypaKPIGRp5xSqsFkJkihyDr1Va2+jtu56H9s67XwQO2FCilAsCDOC6bebgqh9xGa9YIa/f9gE7fRnLarq0s+V2rIEyOWQB4VYY4UDm1JiTU4ODsKgdONYAJQ6lJrtV9wXF03qHu/CWEgozHYBwqBUhyN1tmzX3/xX+IHbZPDy6DFjK8/zXBb1AVkwzcaMLKaUlfr8PtZ04QAkbC+G2Yyaqmstq1endl1ID6MhwTduzu7svkyJPUvj9vXTJXsKsXxOfzVDcJBNI2Zb1VeRsnn/pgWXLuu5onno73BraVmpBiwfll08zUL7QS/BDbMwYmHtgAdWzhIUCctSha4J+laiN1WJ1bAPfHP/tKVpo22flcp1MCLTv+Zlg/32CPBbxFP4RQRVRFeVNp7xUMol0T8TPnER8+XxF0NOLl25ryh2qIHjUkPUO4IidtF0rzM+MdQwlg8hv4P67Blcj0Ljb9mJ1XOb/BR3AO/SOMQoVWNeV6OpQBVVV9tipez39uVrOGlMPhRCza4Zf0GEBhhfmn66NdJ4yrIh2CQIsGLy4kef+XQ3jQ+Ru5DRZg6hOegKYhzLrvPujXEN4TA8c64yVBcjYnyWWu+reWLx5QYk2wvIV26+bsAj/ZOpePjlAD5zjvqBXnMCVM8i9UWbb3Hyo4KPt6f5P6uAt68Rk+MJa7ruGdpr5lqhgLP2YTkqiG8jCrXxBGXVtw6Fi02x5q1V+6WxyUqF6RIAshPKPhm6SM/gHhrEnriThivfUKxgk+lozef8el/Q31qKHOxlayoT4/fhyzoucATxExDzk2dTKAbQ9fecW6zGPGX8HOiv1rtCjMCw8Ee/ZGW36ZCB2MQDgoiUyoH/cYEtHvDO4Ys+2ozo vfdhpWTv 1BFCSt4gRf/KV/zNcBB4PEO2Svm9vOW/NUhwA5ZVJDEMCJyPCuXAUQ0w0WX01dAZkTEUub4EGuOaUgb/Pz1YwQlHNP+e9MjYIpafbtVen9oxLnN/90iiwWwczbSIMQl1Z6gtaTR/OjRVc4cBvZo8oIHIaBeDKaSMScm4ghce/1MhH0LoxO4eIoIL/WgJ9ZJCPmCyCRprwufREiNM/CzVmKmMn1w== 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: Ryan Roberts writes: > On 19/10/2023 06:49, Huang, Ying wrote: >> Ryan Roberts writes: >> >>> On 18/10/2023 07:55, Huang, Ying wrote: >>>> Ryan Roberts writes: >>>> >> >> [snip] >> >>>>> diff --git a/include/linux/swap.h b/include/linux/swap.h >>>>> index a073366a227c..35cbbe6509a9 100644 >>>>> --- a/include/linux/swap.h >>>>> +++ b/include/linux/swap.h >>>>> @@ -268,6 +268,12 @@ struct swap_cluster_info { >>>>> struct percpu_cluster { >>>>> struct swap_cluster_info index; /* Current cluster index */ >>>>> unsigned int next; /* Likely next allocation offset */ >>>>> + unsigned int large_next[]; /* >>>>> + * next free offset within current >>>>> + * allocation cluster for large folios, >>>>> + * or UINT_MAX if no current cluster. >>>>> + * Index is (order - 1). >>>>> + */ >>>>> }; >>>>> >>>>> struct swap_cluster_list { >>>>> diff --git a/mm/swapfile.c b/mm/swapfile.c >>>>> index b83ad77e04c0..625964e53c22 100644 >>>>> --- a/mm/swapfile.c >>>>> +++ b/mm/swapfile.c >>>>> @@ -987,35 +987,70 @@ static int scan_swap_map_slots(struct swap_info_struct *si, >>>>> return n_ret; >>>>> } >>>>> >>>>> -static int swap_alloc_cluster(struct swap_info_struct *si, swp_entry_t *slot) >>>>> +static int swap_alloc_large(struct swap_info_struct *si, swp_entry_t *slot, >>>>> + unsigned int nr_pages) >>>> >>>> This looks hacky. IMO, we should put the allocation logic inside >>>> percpu_cluster framework. If percpu_cluster framework doesn't work for >>>> you, just refactor it firstly. >>> >>> I'm not sure I really understand what you are suggesting - could you elaborate? >>> What "framework"? I only see a per-cpu data structure and >>> scan_swap_map_try_ssd_cluster(), which is very much geared towards order-0 >>> allocations. >> >> I suggest to share as much code as possible between order-0 and order > >> 0 swap entry allocation. I think that we can make >> scan_swap_map_try_ssd_cluster() works for order > 0 swap entry allocation. >> > > [...] > >>>>> + /* >>>>> + * If scan_swap_map_slots() can't find a free cluster, it will >>>>> + * check si->swap_map directly. To make sure this standby >>>>> + * cluster isn't taken by scan_swap_map_slots(), mark the swap >>>>> + * entries bad (occupied). (same approach as discard). >>>>> + */ >>>>> + memset(si->swap_map + offset + nr_pages, SWAP_MAP_BAD, >>>>> + SWAPFILE_CLUSTER - nr_pages); >>>> >>>> There's an issue with this solution. If the free space of swap device >>>> runs low, it's possible that >>>> >>>> - some cluster are put in the percpu_cluster of some CPUs >>>> the swap entries there are marked as used >>>> >>>> - no free swap entries elsewhere >>>> >>>> - nr_swap_pages isn't 0 >>>> >>>> So, we will still scan LRU, but swap allocation fails, although there's >>>> still free swap space. > > I'd like to decide how best to solve this problem before I can figure out how > much code sharing I can do for the order-0 vs order > 0 allocators. > > I see a couple of potential options: > > 1) Manipulate nr_swap_pages to include the entries that are marked SWAP_MAP_BAD, > so when reserving a new per-order/per-cpu cluster, subtract SWAPFILE_CLUSTER, > and then add nr_pages for each allocation from that cluster. > > 2) Don't mark the entries in the reserved cluster as SWAP_MAP_BAD, which would > allow the scanner to steal (order-0) entries. The scanner could set a flag in > the cluster info to mark it as having been allocated from by the scanner, so the > next attempt to allocate a high order from it would cause discarding it as the > cpu's current cluster and trying to get a fresh cluster from the free list. > > While option 2 is a bit more complex, I prefer it as a solution. What do you think? I think that this is a good choice to start with. We may build more optimization on top of it if necessary. -- Best Regards, Huang, Ying