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 EFE0AC54E58 for ; Thu, 21 Mar 2024 09:22:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F1516B007B; Thu, 21 Mar 2024 05:22:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 278B56B0082; Thu, 21 Mar 2024 05:22:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F3BD6B0083; Thu, 21 Mar 2024 05:22:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ECC336B007B for ; Thu, 21 Mar 2024 05:22:22 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 89632A03EF for ; Thu, 21 Mar 2024 09:22:22 +0000 (UTC) X-FDA: 81920505324.04.25940BD Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 9DDD94000D for ; Thu, 21 Mar 2024 09:22:20 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ijXBS0tO; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711012940; a=rsa-sha256; cv=none; b=Y5ZjLc0hOi7rK4De3/Nf16LmVyChvoiDX+VOarTNGkXAULMHNKhkM7aYw396UmQ5HbHFur SWrbqnXGiRw+OfF/mQl/904EwRizmvLLgHIBwCB2MBTmKLNgXW8Nquf34ZU+N+pQ3RC24/ SGL4yGpI6sK3+28li5yLGyv1cVDzLLA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ijXBS0tO; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.172 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711012940; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=h/SfnxPuh9EWRzGMLOisZaa8G0MP0iNbrgH6LWOByo0=; b=iEusRdW/M0N3kpqSes6zulU2jot2TKj0w9SrpDho3EoNGWTpLvH4lcq8hq0CLpPK/Yzs4r i2Q9A8o4N2CM3x3885B8I1tLlAjjfV4XIunnFuKvzTV+fS5OtSXb+imm5Jml4RKfE+9q14 KznQQG+pUNCA5elgq3UGv4dDkeFnMjQ= Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-4d4226edea8so278569e0c.1 for ; Thu, 21 Mar 2024 02:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711012940; x=1711617740; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=h/SfnxPuh9EWRzGMLOisZaa8G0MP0iNbrgH6LWOByo0=; b=ijXBS0tOZx4d3aX/vbVqSVrm7xF+ebLHHP6elGYqSdzE1bTEYUHlDseOvWmGMvO6He 7OWeO50VRlib0lFmPV0khH/Ac9WEWfPFUQG/oOIpnJ/fl90hRG9xHuaWYnXz+o8nXn/B gooY/UfgESfMtRggSdKgDSN/OhrsFEa6paWr9YBnPGkeVuuOR51Je0RmaA+TZHVcQ1ny ayn71cFoDi9baIvRrqhS6VDjVu94f9J07vII+gR9x8uLht1us0HtBu3pNwgO2azrpnBU vPJmv1caoiuUxOYsl18O454SvVX0azLpfEeD3HKdRDnxWRSDudTehR/ir5EZZ9ssZSe/ eHHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711012940; x=1711617740; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=h/SfnxPuh9EWRzGMLOisZaa8G0MP0iNbrgH6LWOByo0=; b=XCSMqxXXe6rDIRDYoSbJTT8psuqsfW2dlwP8E9gSV/nH6RmQliqGKQfXn8vbeL+6S4 IPiEoqB/xt03tj8gRf7GPqqVKei5vNfB9p/JvbDZmJz78JSH0tK20CBtpXVoPZ6luV/+ pQCtwjHpHwPlO6CVn3/UMfDMmK193uXRY7G8Uqz4ptiFnqyS2c4ctB5Zm6T40wDab+Bv zHnxoEMpOgvRHXyAKvXXVYp0bzbRnkC6C0C/yc0DSYVV0UGglEkH2pNLl/peJiAj+r7j A+w2qj14oLV518HoPw7yZh4aKvuUBnKclJdrhMusclqpqWOCzAh/pNZ6EH1/lPmiFHvF jGFw== X-Forwarded-Encrypted: i=1; AJvYcCXq/uKPAFaAgtUA8YzxBiVQRa2n8sZYAp77mBX6BB523RPuTJYg+uPj6+Z0sCVHmEmdil0s9nA+jL7d7dn5au72Y8I= X-Gm-Message-State: AOJu0Yxnq7CeA1nr9AYRVmZGVSQjMil+FYmvG56BlcHObTrYFN5SjJ+P 9AXSRae4ZVkaeyvoymKenZMUZR3KcXOsCa5nNbovOagncsKBDIq3+F1+wIsVWd8WbCkukRZGhuC aHb88qC7+cTVjWeUhJzHIIhc2OfA= X-Google-Smtp-Source: AGHT+IFjxfacrA08eDuMnbIwrfE3EdhXWfFxu/f74a3M1J4/YRzGYst3XpF6SN5AzPOoeMmfiCDds/4MOZ1COSGr35U= X-Received: by 2002:a05:6122:3659:b0:4c0:2d32:612f with SMTP id dv25-20020a056122365900b004c02d32612fmr5502675vkb.15.1711012939590; Thu, 21 Mar 2024 02:22:19 -0700 (PDT) MIME-Version: 1.0 References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-6-21cnbao@gmail.com> <87wmq3yji6.fsf@yhuang6-desk2.ccr.corp.intel.com> <87sf0rx3d6.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzm0wblq.fsf@yhuang6-desk2.ccr.corp.intel.com> <9ec62266-26f1-46b6-8bb7-9917d04ed04e@arm.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 21 Mar 2024 22:22:08 +1300 Message-ID: Subject: Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole To: Ryan Roberts Cc: "Huang, Ying" , Matthew Wilcox , akpm@linux-foundation.org, linux-mm@kvack.org, chengming.zhou@linux.dev, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mhocko@suse.com, nphamcs@gmail.com, shy828301@gmail.com, steven.price@arm.com, surenb@google.com, wangkefeng.wang@huawei.com, xiang@kernel.org, yosryahmed@google.com, yuzhao@google.com, Chuanhua Han , Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9DDD94000D X-Stat-Signature: qxett4dzj79ergpkcg615ka79r6igh9e X-Rspam-User: X-HE-Tag: 1711012940-519739 X-HE-Meta: U2FsdGVkX1+2pol1C+AcaGK7fKy7aUQqGGMkyo+0gKahHUCloyaxiYx3yQ8rpFNlu6ext1Kc/ttcfAlei4sE9iOVo77h5rC/z6RjVBG3DVIN/Apc6fWv3/+Mrd2rGtxn47F+shBIm0u2ZUnnpn+LW7mxPtoDkesNjUpgExta3sFMrlbpnWlIXdcYPvBrtPP8qBNkZ403fCQMSGBzKqca/7Xkx8JxelDdkUgLpXWCGfjKoZvEkvxdRIAOckUnVdGft+zixP4Hn+ZhQjDfTKPdmCPqNc9OqOW+Sxj2ngKT0WhOjBkguEpKw5yjvmZ35Pi8dgetyjRLqegsw9X/aZoIFfZFcpyf1UF32e21MOYAKX/yVuohETJIcLbh41HYLq0O/bLe2w3gr8O5SfMQAMkBzUKMBdsBLb7v3tuomz4T3jMY3O7g3HCo87xDlifWX31mLpCsW7olimEJMuVpSE6GBFGfGe1Ys7RHhM7lSGW2Ph+Vdd1vFrH5KmvZ/GxErpWG82cvlnFUO40i1SVoLMP2DpTIFvuhsPhA6yaK02zlAtdl3mdvGzN1awxbR99JRC4GmA2tZPFaLCxmt2aisNX3B9ApQgFN/U7BNo6hDUnushLgB5mXB7uP8M3MIKBjieMrJmeh8JyL1+ljHk0clKQzbckg1kQ28pbXJ0g78YJte13dBIOLeVg4Vln65TUJoaaHk4JJ3lZiWHxjBKA9nzqo0PWFOlfGq2HQQLp7RMBcHXiw9sP94EgAOvBgvxRTxvvga9OTcNrGoLDi6r2zLwt5g8XvlpKDOglgHobj99VRzhz+7CLFvt82DkXuJ3Jv/YaNRJj30vYyirwUdvuShS9+l40OEgA3NaADpxkudxLT5JAGKkO2xcnyGlC0Hq2mnt6prGLvwghY0hyElhuwVUsDsvM9NahK+dKzzbuG6GmfYXo3rrWJoolvku0WMgyRYcZNImb2biUQzc7vQ2FQj3I UT/nu+3L weVcaH62Dwk/IFAu31LU+s2L49q5uTi5lDY6mAxx1WPz0B92kD2iMOxzTaTX8aP0aZ7/LX9d9yboDL4bfLQCYKEpA9GddT/NFDIsI+3mNrfEcD+UFZJVYXmIebKKIJn7swTuxFb5H+SBWT/qSt3xIZKCtcjNhHlZCFQDVTs9tE4EhyPr3OC0LGwD1e7+vjEC4uC4S/upbr930FLU6je5sUN6RXjlB/kN8s/NpNl9F3Vsb4tPGAWozHi9wna3sygPlrDBQ1mNYqvdxyjkrX3O/KDjbxdOLm3xr4g1zJofqbs8ZIoyn/u43AZlTsR/kouNu6Jo+Z+16e9/uXUe8Cu37GxrpJBGIqHxrnKzrktOWYTJTBWC1h9BJ8QOWBbb8Mr5t4F/8zAe7ege3CxSMn5GG2G6M4yii867kc2C4 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Tue, Mar 19, 2024 at 10:05=E2=80=AFPM Ryan Roberts wrote: > > On 19/03/2024 06:27, Barry Song wrote: > > On Tue, Mar 19, 2024 at 5:45=E2=80=AFAM Ryan Roberts wrote: > >> > >>>>> I agree phones are not the only platform. But Rome wasn't built in = a > >>>>> day. I can only get > >>>>> started on a hardware which I can easily reach and have enough hard= ware/test > >>>>> resources on it. So we may take the first step which can be applied= on > >>>>> a real product > >>>>> and improve its performance, and step by step, we broaden it and ma= ke it > >>>>> widely useful to various areas in which I can't reach :-) > >>>> > >>>> We must guarantee the normal swap path runs correctly and has no > >>>> performance regression when developing SWP_SYNCHRONOUS_IO optimizati= on. > >>>> So we have to put some effort on the normal path test anyway. > >>>> > >>>>> so probably we can have a sysfs "enable" entry with default "n" or > >>>>> have a maximum > >>>>> swap-in order as Ryan's suggestion [1] at the beginning, > >>>>> > >>>>> " > >>>>> So in the common case, swap-in will pull in the same size of folio = as was > >>>>> swapped-out. Is that definitely the right policy for all folio size= s? Certainly > >>>>> it makes sense for "small" large folios (e.g. up to 64K IMHO). But = I'm not sure > >>>>> it makes sense for 2M THP; As the size increases the chances of act= ually needing > >>>>> all of the folio reduces so chances are we are wasting IO. There ar= e similar > >>>>> arguments for CoW, where we currently copy 1 page per fault - it pr= obably makes > >>>>> sense to copy the whole folio up to a certain size. > >>>>> " > >> > >> I thought about this a bit more. No clear conclusions, but hoped this = might help > >> the discussion around policy: > >> > >> The decision about the size of the THP is made at first fault, with so= me help > >> from user space and in future we might make decisions to split based o= n > >> munmap/mremap/etc hints. In an ideal world, the fact that we have had = to swap > >> the THP out at some point in its lifetime should not impact on its siz= e. It's > >> just being moved around in the system and the reason for our original = decision > >> should still hold. > > > > Indeed, this is an ideal framework for smartphones and likely for > > widely embedded > > Linux systems utilizing zRAM. We set the mTHP size to 64KiB to > > leverage CONT-PTE, > > given that more than half of the memory on phones may frequently swap o= ut and > > swap in (for instance, when opening and switching between apps). The > > ideal approach > > would involve adhering to the decision made in do_anonymous_page(). > > > >> > >> So from that PoV, it would be good to swap-in to the same size that wa= s > >> swapped-out. But we only kind-of keep that information around, via the= swap > >> entry contiguity and alignment. With that scheme it is possible that m= ultiple > >> virtually adjacent but not physically contiguous folios get swapped-ou= t to > >> adjacent swap slot ranges and then they would be swapped-in to a singl= e, larger > >> folio. This is not ideal, and I think it would be valuable to try to m= aintain > >> the original folio size information with the swap slot. One way to do = this would > >> be to store the original order for which the cluster was allocated in = the > >> cluster. Then we at least know that a given swap slot is either for a = folio of > >> that order or an order-0 folio (due to cluster exhaustion/scanning). C= an we > >> steal a bit from swap_map to determine which case it is? Or are there = better > >> approaches? > > > > In the case of non-SWP_SYNCHRONOUS_IO, users will invariably invoke > > swap_readahead() > > even when __swap_count(entry) equals 1. This leads to two scenarios: > > swap_vma_readahead > > and swap_cluster_readahead. > > > > In swap_vma_readahead, when blk_queue_nonrot, physical contiguity > > doesn't appear to be a > > critical concern. However, for swap_cluster_readahead, the focus > > shifts towards the potential > > impact of physical discontiguity. > > When you talk about "physical [dis]contiguity" I think you are talking ab= out > contiguity of the swap entries in the swap device? Both paths currently a= llocate > order-0 folios to swap into, so neither have a concept of physical contig= uity in > memory at the moment. > > As I understand it, roughly the aim is to readahead by cluster for rotati= ng > disks to reduce seek time, and readahead by virtual address for non-rotat= ing > devices since there is no seek time cost. Correct? >From the code comment, I agree with this. * It's a main entry function for swap readahead. By the configuration, * it will read ahead blocks by cluster-based(ie, physical disk based) * or vma-based(ie, virtual address based on faulty address) readahead. > > Note that today, swap-out on supports (2M) THP if the swap device is > non-rotating. If it is rotating, the THP is first split. My swap-out seri= es > maintains this policy for mTHP. So I think we only really care about > swap_vma_readahead() here; we want to teach it to figure out the order of= the > swap entries and swap them into folios of the same order (with a fallback= to > order-0 if allocation fails). I agree we don't need to care about devices which rotate. > > > > > struct page *swapin_readahead(swp_entry_t entry, gfp_t gfp_mask, > > struct vm_fault *vmf) > > { > > struct mempolicy *mpol; > > pgoff_t ilx; > > struct folio *folio; > > > > mpol =3D get_vma_policy(vmf->vma, vmf->address, 0, &ilx); > > folio =3D swap_use_vma_readahead() ? > > swap_vma_readahead(entry, gfp_mask, mpol, ilx, vmf) : > > swap_cluster_readahead(entry, gfp_mask, mpol, ilx); > > mpol_cond_put(mpol); > > > > if (!folio) > > return NULL; > > return folio_file_page(folio, swp_offset(entry)); > > } > > > > In Android and embedded systems, SWP_SYNCHRONOUS_IO is consistently uti= lized, > > rendering physical contiguity less of a concern. Moreover, instances wh= ere > > swap_readahead() is accessed are rare, typically occurring only in scen= arios > > involving forked but non-CoWed memory. > > Yes understood. What I'm hearing is that for Android at least, stealing a= bit > from swap_map to remember if a swap entry is the order marked in the clus= ter or > order-0 won't be noticed because almost all entries have swap count =3D= =3D 1. From > memory, I think swap_map is 8 bits, and 2 bits are currently stolen, leav= ing 6 > bits (count =3D 64) before having to move to the swap map continuation st= uff. Does > anyone know what workloads provoke this overflow? What are the consequenc= es of > reducing that count to 32? I'm not entirely clear on why you need bits to record this information. Could you provide more details? > > > > > So I think large folios swap-in will at least need three steps > > > > 1. on SWP_SYNCHRONOUS_IO (Android and embedded Linux), this has a very > > clear model and has no complex I/O issue. > > 2. on nonrot block device(bdev_nonrot =3D=3D true), it cares less abou= t > > I/O contiguity. > > 3. on rot block devices which care about I/O contiguity. > > I don't think we care about (3); if the device rotates, we will have spli= t the > folio at swap-out, so we are only concerned with swapping-in order-0 foli= os. > > > > > This patchset primarily addresses the systems utilizing > > SWP_SYNCHRONOUS_IO(type1), > > such as Android and embedded Linux, a straightforward model is establis= hed, > > with minimal complexity regarding I/O issues. > > Understood. But your implication is that making swap_vma_readahead() larg= e folio > swap-in aware will be complex. I think we can remember the original order= in the > swap device, then it shouldn't be too difficult - conceptually at least. Currently, I can scan PTE entries and determine the number of contiguous swap offsets. The swap_vma_readahead code to support large folios already exists in OPPO's repository. I'm confident that it can be cleaned up and submitted to LKML. However, the issue lies with the readahead policy. We typically prefer using the same 64KiB size as in do_anonymous_page(), but clearly, this isn't the preference for Ying :-) > > > > >> > >> Next we (I?) have concerns about wasting IO by swapping-in folios that= are too > >> large (e.g. 2M). I'm not sure if this is a real problem or not - intui= tively I'd > >> say yes but I have no data. But on the other hand, memory is aged and > >> swapped-out per-folio, so why shouldn't it be swapped-in per folio? If= the > >> original allocation size policy is good (it currently isn't) then a fo= lio should > >> be sized to cover temporally close memory and if we need to access som= e of it, > >> chances are we need all of it. > >> > >> If we think the IO concern is legitimate then we could define a thresh= old size > >> (sysfs?) for when we start swapping-in the folio in chunks. And how bi= g should > >> those chunks be - one page, or the threshold size itself? Probably the= latter? > >> And perhaps that threshold could also be used by zRAM to decide its up= per limit > >> for compression chunk. > > > > > > Agreed. What about introducing a parameter like > > /sys/kernel/mm/transparent_hugepage/max_swapin_order > > giving users the opportunity to fine-tune it according to their needs. = For type1 > > users specifically, setting it to any value above 4 would be > > beneficial. If there's > > still a lack of tuning for desktop and server environments (type 2 and = type 3), > > the default value could be set to 0. > > This sort of thing sounds sensible to me. But I have a history of proposi= ng > crappy sysfs interfaces :) So I'd like to hear from others - I suspect it= will > take a fair bit of discussion before we converge. Having data to show tha= t this > threshold is needed would also help (i.e. demonstration that the intuitio= n that > swapping in a 2M folio is often counter-productive to performance). > I understand. The ideal swap-in size is obviously a contentious topic :-) However, for my real use case, simplicity reigns: we consistently adhere to a single size - 64KiB. > > > >> > >> Perhaps we can learn from khugepaged here? I think it has programmable > >> thresholds for how many swapped-out pages can be swapped-in to aid col= lapse to a > >> THP? I guess that exists for the same concerns about increased IO pres= sure? > >> > >> > >> If we think we will ever be swapping-in folios in chunks less than the= ir > >> original size, then we need a separate mechanism to re-foliate them. W= e have > >> discussed a khugepaged-like approach for doing this asynchronously in = the > >> background. I know that scares the Android folks, but David has sugges= ted that > >> this could well be very cheap compared with khugepaged, because it wou= ld be > >> entirely limited to a single pgtable, so we only need the PTL. If we n= eed this > >> mechanism anyway, perhaps we should develop it and see how it performs= if > >> swap-in remains order-0? Although I guess that would imply not being a= ble to > >> benefit from compressing THPs for the zRAM case. > > > > The effectiveness of collapse operation relies on the stability of > > forming large folios > > to ensure optimal performance. In embedded systems, where more than hal= f of the > > memory may be allocated to zRAM, folios might undergo swapping out befo= re > > collapsing or immediately after the collapse operation. It seems a > > TAO-like optimization > > to decrease fallback and latency is more effective. > > Sorry, I'm not sure I've understood what you are saying here. I'm not entirely clear on the specifics of the khugepaged-like approach. However,a major distinction for Android is that its folios may not remain in memory for extended periods. If we incur the cost of compaction and page migration to form a large folio, it might soon be swapped out. Therefore, a potentially more efficient approach could involve a TAO-like pool, where we obtain large folios at a low cost. > > > > >> > >> I see all this as orthogonal to synchronous vs asynchronous swap devic= es. I > >> think the latter just implies that you might want to do some readahead= to try to > >> cover up the latency? If swap is moving towards being folio-orientated= , then > >> readahead also surely needs to be folio-orientated, but I think that s= hould be > >> the only major difference. > >> > >> Anyway, just some thoughts! > > > > Thank you very much for your valuable and insightful deliberations. > > > >> > >> Thanks, > >> Ryan > >> > > Thanks Barry