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 35786CD4F4B for ; Wed, 4 Sep 2024 23:10:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 963268D0006; Wed, 4 Sep 2024 19:10:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 912278D0001; Wed, 4 Sep 2024 19:10:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 766948D0006; Wed, 4 Sep 2024 19:10:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5861C8D0001 for ; Wed, 4 Sep 2024 19:10:45 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 027B5A143A for ; Wed, 4 Sep 2024 23:10:44 +0000 (UTC) X-FDA: 82528602450.08.4D3C35D Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 3E86F4000C for ; Wed, 4 Sep 2024 23:10:42 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eb9CwLub; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 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=1725491345; 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=oAn3JxDFP21r4YFSVaV3PAOM9PQK/tnDHy5YesZx4b0=; b=HJm1Ky23H9AfZ8IPSrG0R6+4I1y6IBZmfxoa/ql7w9dZ7o2rsvaDkM+BkWIX/gftnzvMLq hTJqX3GQLR4YcvE5h1pYkTcVpcq42pEqjYb9bq/lij+djhpQWTgqP5KMs+t4FFYrXDqT8/ DyQdorhLRKKb/U9e5RERnzoAJ05RM08= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725491345; a=rsa-sha256; cv=none; b=5xQXW74InmKw2KP7nLOCA7BibF9cdGPn1VHifXkLzwK4bJK35flJOhb1E+URkgqxTHBBuR TNUckuweNB15/zsGRTEjE+U401mbYle+ZMZPjChy2XCliweEGTL5chv+wnYXd+Oe2H5Wz6 FW9lu0A/l2zPjSs6eZbZkjGySjKmEaE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eb9CwLub; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4fce6ff78c1so60120e0c.3 for ; Wed, 04 Sep 2024 16:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725491441; x=1726096241; 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=oAn3JxDFP21r4YFSVaV3PAOM9PQK/tnDHy5YesZx4b0=; b=eb9CwLubgW7uHBFYPqvDtoCVPFoVqZZuXL3m+vS68oyXngkwsNOri75MAbtJlcsFc3 SDWIp0LnQarxoDceljfjWb5jPFEaol8yDBMTlmUliqoc+hoKNkKWpu7Wh2WtJwgy8GY+ BwpOQ9ozNsgSg3qeu+xAw1AwAiPeyrAC7dFA0teIyrHDUDxy5FZD9ZbP0gld/ZlyVgsc 3Os0oY+5zrK0cDMwKEps6HwoUyXNO9qksNahgEPE6Pv4c/RiQBhHyRFGyp1On2HbgGpt GHCgC4zU3Pk4hEXhMwGuKsU0zRwbQsRZdRrj3cxtl7sxAvxoSfJG61KzeoEPrJ5Q/2AQ qfag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725491441; x=1726096241; 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=oAn3JxDFP21r4YFSVaV3PAOM9PQK/tnDHy5YesZx4b0=; b=teVLvqJRcZ+gc1I3pP8WuuHQO9mAE3H6qrv/7wTfc4T/bNYgxdLVKN2uqa7//uVgjm l5b0hF+3bQuVvjYzlJF6BQtaoe8Rv0wqx5ZHw6Rz8yEhtAtW9uigznuejt9QPCMZSGJi 8/X9IRr1AnQcVzUaIHY6qsefvmJgARpGYm6YH5KyIPkEECbvFBXpXNWMYYcbrt2k6JaK 5zT3U53HaPA85NEyddb6sgA3RoaI70EXPGuMr6l6igdgyGt7eVjVZpCB54U89h8JUxoY ONnzsl+0IwJy52NzAZreA7AcAgqjDV4eS8TXO8n17v6XfCGPrVBzWiAudNN6r7Si/Xh3 mP9Q== X-Forwarded-Encrypted: i=1; AJvYcCWGcDjYT/XDLse/pXnu/TUJFt3HGLxqQsZBQjMf2RIvw/pm9IpFF36w6gT5NnfgkcJDLy8ntOT++w==@kvack.org X-Gm-Message-State: AOJu0YwyjlrlNTPnOFq9InxCS55PaxAXvZZ1SwFdSjh/OYO5wPqLSz6q gS7q9Vmr6QrfRl4fbJGMfSUo/EP49Glzf5BVQJ5ah6J9OSvqVQsiZ+XGx/JL4eNXhi9Sozk4XgQ w2fJBbBBmwWob52ypzMmKpyQfgL0= X-Google-Smtp-Source: AGHT+IF0nxgkJPT1EowO940ec9V3dG6+UpfFlus+7DDGlDtsdpQ3GiO+IzEIUUDE4WmYDd3XylSpIn26qPRbYxqarMQ= X-Received: by 2002:a05:6122:20a1:b0:4f5:2276:1366 with SMTP id 71dfb90a1353d-4ffe4a58f0dmr21580879e0c.3.1725491441030; Wed, 04 Sep 2024 16:10:41 -0700 (PDT) MIME-Version: 1.0 References: <20240821074541.516249-1-hanchuanhua@oppo.com> <20240821074541.516249-3-hanchuanhua@oppo.com> <20240903130757.f584c73f356c03617a2c8804@linux-foundation.org> <94eb70cd-b508-42ef-b5d2-acc29e22eb0e@gmail.com> In-Reply-To: <94eb70cd-b508-42ef-b5d2-acc29e22eb0e@gmail.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 5 Sep 2024 11:10:29 +1200 Message-ID: Subject: Re: [PATCH v7 2/2] mm: support large folios swap-in for sync io devices To: Usama Arif Cc: Yosry Ahmed , Andrew Morton , Kairui Song , hanchuanhua@oppo.com, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, hch@infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: j13rk1w5f1igj4181hzct3pegpa8ekn4 X-Rspamd-Queue-Id: 3E86F4000C X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1725491442-603716 X-HE-Meta: U2FsdGVkX18m6HeNTc5Ks5keOmlOOjoLst1Uo3rtaemIEqnXrrZ+yWKjB3lUyTo4c8NE3t9VyHJh82Yqc3pkV1nRlLrRLGJ+bL/lH0tWZtoJj/186GLn9MuwwcKrdNibVJbG976vodWYVh2YwJZhM3Ve00Zww0/l3cBWLIQlaD8pFBRFtta9Gn6cZJXXQYFHkMumCmiiOHuQNhvSw+Jv65uU6dmamsZxV9Ql0KF/NIIwOcVu9GQnh0G+d/aLniiyz+0C35bMJwcaFNZwGPhGBKkTxWXdSbNX5ihQl0zOCCKgF0UjcR/gL86psRYnbBMOKVd1eUnCTJ7U8fubcD3pYkCWH254Nb3Yba44MUJu9hF6gm5lrqdp6s/UvbbOUPhWORLUXTNhsVv0odtJ+nmLyDjouuiaOOOuckSMUSWjpmjmdGtEsI1th091cm1wc0UbM42R0Mn5j/9URkWRWXu8M7W2TRMpdq5i/OG/F2GbUVyfLzO527qXEn6pFs7XfSxrjfuMbvmJvJbXnMP5el87gXvdaa7SccVouSoLxZPzU96DODX/QEPmVcojVDDdFNkHPQzeTzHxJwMYDwf8O3kRzhTQFlWpOgJ32DLPvZ3bXXoG+xzRzWUXcc4Lt4crdiucleSjxxpoUhLJxefsOKG6cWa1KwZfvchnenh/ajMhEf4ibVRwiJ57o3fMbhoMG8/SHhBMVQe2dWVN2HDA/0uvWCwSi1I5f3OizLtRNAHxK3S+oYOG3nc1VJauO33Dd6kkyqWNPmu4utH5YsV1JxKycVJHNxqlnxK0RPIXvmRJf50iCzPcevs9S78T8x/rzKQMrGRzt9grsUrsyxb+AjB/JBNOdkfCcR72pOb4ZAfh3vWHxXsQpic8BDNFnEyeV9l3qvkUqytJ5dO8TnrLnAO3TmzCokmFVV2v0RhiqbqNXzmZSQCAadLZR2tqTiMtMADeAjXzST7OGEOSTIuovZ/ So0jv7Mp 7mNrrKlUBuMMSrNltlTIlbSaUyKlQPFa2wW4eKlXzCWnNEmLl/PV5Yfw/nSCICOfWRFBGAORIH2m0grqMgprxKX33ajQ9FNtPMQncJxbaDLkIobIsO8AUB26HfmpM15EQx+i1axpRyQrkYGQxVSuUlNdcPGjY/N98EaJa+eKepMPwFdEE3ytlCMQUjmlUj70YAPRnPePjfytSykhYDqpDg/c0bOrjl52per2tfaPm8obbDHF/77Eqb5q0sHmNq45VDsS+0nfIczgxz6tY2A2pfqGiEjqJnbkI4MoxP8AX1dVyGGdcxtRgjAzUL7XcAt5JjwhBb9nW5ONhDC8GQcejCUh0kqwA9RwEwR1QBKz/VwVmBKpL3aTaeLzPFOEHuPbrriIDwgZgzYt7fryXwrTC5NLmp0xFbGRaYWP4SReHDeyhjvyTkjLkVz0NF6A+UQU000liUxcnKvwLuyW57VP0xuj0vQ== 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 Thu, Sep 5, 2024 at 9:30=E2=80=AFAM Usama Arif = wrote: > > > > On 03/09/2024 23:05, Yosry Ahmed wrote: > > On Tue, Sep 3, 2024 at 2:36=E2=80=AFPM Barry Song <21cnbao@gmail.com> w= rote: > >> > >> On Wed, Sep 4, 2024 at 8:08=E2=80=AFAM Andrew Morton wrote: > >>> > >>> On Tue, 3 Sep 2024 11:38:37 -0700 Yosry Ahmed = wrote: > >>> > >>>>> [ 39.157954] RBP: 0000000000000000 R08: 0000000000000000 R09: 000= 0000000000007 > >>>>> [ 39.158288] R10: 0000000000000000 R11: 0000000000000246 R12: 000= 0000000000001 > >>>>> [ 39.158634] R13: 0000000000002b9a R14: 0000000000000000 R15: 000= 07ffd619d5518 > >>>>> [ 39.158998] > >>>>> [ 39.159226] ---[ end trace 0000000000000000 ]--- > >>>>> > >>>>> After reverting this or Usama's "mm: store zero pages to be swapped > >>>>> out in a bitmap", the problem is gone. I think these two patches ma= y > >>>>> have some conflict that needs to be resolved. > >>>> > >>>> Yup. I saw this conflict coming and specifically asked for this > >>>> warning to be added in Usama's patch to catch it [1]. It served its > >>>> purpose. > >>>> > >>>> Usama's patch does not handle large folio swapin, because at the tim= e > >>>> it was written we didn't have it. We expected Usama's series to land > >>>> sooner than this one, so the warning was to make sure that this seri= es > >>>> handles large folio swapin in the zeromap code. Now that they are bo= th > >>>> in mm-unstable, we are gonna have to figure this out. > >>>> > >>>> I suspect Usama's patches are closer to land so it's better to handl= e > >>>> this in this series, but I will leave it up to Usama and > >>>> Chuanhua/Barry to figure this out :) > >> > >> I believe handling this in swap-in might violate layer separation. > >> `swap_read_folio()` should be a reliable API to call, regardless of > >> whether `zeromap` is present. Therefore, the fix should likely be > >> within `zeromap` but not this `swap-in`. I=E2=80=99ll take a look at t= his with > >> Usama :-) > > > > I meant handling it within this series to avoid blocking Usama > > patches, not within this code. Thanks for taking a look, I am sure you > > and Usama will figure out the best way forward :) > > Hi Barry and Yosry, > > Is the best (and quickest) way forward to have a v8 of this with > https://lore.kernel.org/all/20240904055522.2376-1-21cnbao@gmail.com/ > as the first patch, and using swap_zeromap_entries_count in alloc_swap_fo= lio > in this support large folios swap-in patch? Yes, Usama. i can actually do a check: zeromap_cnt =3D swap_zeromap_entries_count(entry, nr); /* swap_read_folio() can handle inconsistent zeromap in multiple entries */ if (zeromap_cnt > 0 && zeromap_cnt < nr) try next order; On the other hand, if you read the code of zRAM, you will find zRAM has exactly the same mechanism as zeromap but zRAM can even do more by same_pages filled. since zRAM does the job in swapfile layer, there is no this kind of consistency issue like zeromap. So I feel for zRAM case, we don't need zeromap at all as there are duplicat= ed efforts while I really appreciate your job which can benefit all swapfiles. i mean, zRAM has the ability to check "zero"(and also non-zero but same content). after zeromap checks zeromap, zRAM will check again: static int zram_write_page(struct zram *zram, struct page *page, u32 index) { ... if (page_same_filled(mem, &element)) { kunmap_local(mem); /* Free memory associated with this sector now. */ flags =3D ZRAM_SAME; atomic64_inc(&zram->stats.same_pages); goto out; } ... } So it seems that zeromap might slightly impact my zRAM use case. I'm not blaming you, just pointing out that there might be some overlap in effort here :-) > > Thanks, > Usama Thanks Barry