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 B9DCBC4167B for ; Mon, 13 Nov 2023 09:51:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20E3E6B019C; Mon, 13 Nov 2023 04:51:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BEBD6B01A2; Mon, 13 Nov 2023 04:51:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 087636B01A3; Mon, 13 Nov 2023 04:51:11 -0500 (EST) 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 ED2926B019C for ; Mon, 13 Nov 2023 04:51:10 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B950AC03A1 for ; Mon, 13 Nov 2023 09:51:10 +0000 (UTC) X-FDA: 81452462700.22.31CE9B6 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf20.hostedemail.com (Postfix) with ESMTP id 6E98C1C000B for ; Mon, 13 Nov 2023 09:51:06 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699869068; a=rsa-sha256; cv=none; b=hi6dEJg8ZtMtXzP3ZR0MPK1pQYbHl8qVkwhMoaJeBGkIJlLTxeydRoR4unbeI8CjLkTq8b xhFDoCdCaKi72+/yd0gtAJSYuOTfttp9gzBk0cwwndrUdiaXjRyjOK38RWeo5pFbIXyv17 4XDuMZhBJ6/OHZjkpCeaVFZAn3FZaJQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699869068; 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; bh=+z91Bd/LjG1KXfaAPwQXkiigYrbqdfnqwTjLOeZX+G4=; b=y+xfBzsLTeP5ZwI1Da1GpldBAt0om0tzxZ4nIYCMvn8KFsnFoKy3qQQHthCsYw9SxXg189 cYpg+gXaqkZJdZ289dTGWtIEbPxq3f3mZF27IoP4PJClwr9i1tzrruyXmOvNYpJ95KVEJl pav48JW02remfi7NLnPliC9y8oe1iKc= Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4STPhq1SclzPpGX; Mon, 13 Nov 2023 17:46:51 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 13 Nov 2023 17:51:02 +0800 Message-ID: <330c9fd5-fa24-4b07-a3e7-2923e4ab4c89@huawei.com> Date: Mon, 13 Nov 2023 17:51:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] mm: ksm: use more folio api in ksm_might_need_to_copy() Content-Language: en-US To: David Hildenbrand , Matthew Wilcox CC: Andrew Morton , , References: <20231107135216.415926-1-wangkefeng.wang@huawei.com> <20231107135216.415926-2-wangkefeng.wang@huawei.com> <81e0289c-225c-4468-959c-937d3678cb2d@huawei.com> <67eedbab-bf15-4bc3-88ce-36fc074393bd@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm100001.china.huawei.com (7.185.36.93) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6E98C1C000B X-Stat-Signature: en34bzcxe6tbf7xh45qu666c5toengmk X-Rspam-User: X-HE-Tag: 1699869066-693603 X-HE-Meta: U2FsdGVkX195dIo2kCZfQBBzjJenAUq2409cx5ZZMeFnGAAJY99baZseODRTJ8dT4uAO8yFU9aZX4pY26zk0xz7xB7ayNKhlI/rj+k7q1nPpKDhy0Eco/2Hu/2x7F9o0BgJTDBZHNFmLuOsQePcisUPFPruGI/gvhidafEDNhOZ74SwSYgscrerkOHpgVKLcN3AxZdgEvPFJu1MX6oe65nx83WxMmgmXQRJofFqdFPSvuMW8jEhO/0evi6SECqeGuxw6bhbCzlTAswd9n27bp5+PI9lmYXpFqAeBsk2w9Y9PIpRHcWNiGAHHoc+xfFy9Vl+WMi/7v8E64vwrgHLDBOVNHvhciNa7PCE91r5Oth+S8LNCzQrxNXNdxhpQkutFum+vvRgOLCDYnGdSMbF+c+ao8nuAjaxOkVp77h290OM5AeCShR11xrB54F4QMjLW0BBWKGW7y/VcQ2COQRdP00nkbX8dIQeItZHECPgyi13iqQSanImHIWXOV6hZVSgtSEnm/Oxab+aQYEBzjRnQNhExH9FZDnKqjlnaZ6UMcaQyuFx4QKpND/0bWAU4Y4r7s+lrO1rYEPgL3aJlL3t84J9Sk1T/b7+z1ynVvDBjwLUEb5WiImLq01JQQX0LlosB3CqtoMSiDHIAMFg35Gakb63tkwaQH/qiX4k90qodOsBwFOFWE6gx5MFRibwciwVTeD86XPaKclq/9I1SKibmKRp9RJTm13ij+Y8PZrJPd9RjlQlA/hWdvW8PgjwXesRFACjVEVoGGsu4V3KpAoMQ5gUhqwsPaFmqOTaQMnT8jzzbkHv0LQLlQ6UrpTqtNP+09ptMBuaLlReROqo2V480EirZOor0AJNGh2jk54QnQLCAQbCfk4+aeHCCGDhcPC+wv+kdS1ZTalwyks6s6QtjIm5hyQBcLVRWOjAqU6TjKi2RHzlVNLpJmjisj9z7jtV4n3/itkkq4/iTBUlFP/B bU9LlAdg OogQlG709TRttEejn/5REId7KArvldkPCguyf2ASI6bli/GCKXH977qg7rrbyWgn5MVUquLEXL1k33MNSxAa8k4n8tMsZUBI4/VHF6h9Td3EszGiez7n2h94X0yjRG3xC5WrvkUIb9NbKm7qVa4lnfpX6HFt4SDyMNSJu0MG0x0L6cdTqPTmuh0qnsvBwtgfNAQekMkYtyj8Ufibta+3vJD9ISw== 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 2023/11/13 16:32, David Hildenbrand wrote: > On 09.11.23 08:09, Kefeng Wang wrote: >> >> >> On 2023/11/8 21:59, Matthew Wilcox wrote: >>> On Wed, Nov 08, 2023 at 09:40:09AM +0800, Kefeng Wang wrote: >>>> >>>> >>>> On 2023/11/7 22:24, Matthew Wilcox wrote: >>>>> On Tue, Nov 07, 2023 at 09:52:11PM +0800, Kefeng Wang wrote: >>>>>>     struct page *ksm_might_need_to_copy(struct page *page, >>>>>> -            struct vm_area_struct *vma, unsigned long address) >>>>>> +            struct vm_area_struct *vma, unsigned long addr) >>>>>>     { >>>>>>         struct folio *folio = page_folio(page); >>>>>>         struct anon_vma *anon_vma = folio_anon_vma(folio); >>>>>> -    struct page *new_page; >>>>>> +    struct folio *new_folio; >>>>>> -    if (PageKsm(page)) { >>>>>> -        if (page_stable_node(page) && >>>>>> +    if (folio_test_ksm(folio)) { >>>>>> +        if (folio_stable_node(folio) && >>>>>>                 !(ksm_run & KSM_RUN_UNMERGE)) >>>>>>                 return page;    /* no need to copy it */ >>>>>>         } else if (!anon_vma) { >>>>>>             return page;        /* no need to copy it */ >>>>>> -    } else if (page->index == linear_page_index(vma, address) && >>>>>> +    } else if (page->index == linear_page_index(vma, addr) && >>>>> >>>>> Hmm.  page->index is going away.  What should we do here instead? >>>> >>>> Do you mean to replace page->index to folio->index, or kill index from >>>> struct page? >>> >>> I'm asking you what we should do. >>> >>> Tail pages already don't have a valid ->index (or ->mapping). >>> So presumably we can't see a tail page here today.  But will we in >>> future? >> >> I think we could replace page->index to page_to_pgoff(page). > > What the second part of that code does is check whether a page might > have been a KSM page before swapout. > > Once a KSM page is swapped out, we lose the KSM marker. To recover, we > have to check whether the new page logically "fits" into the VMA. > > Large folios are never KSM folios, and we only swap in small folios (and > in the future, once we would swap in large folios, they couldn't have > been KSM folios before). > > So you could return early in the function if we have a large folio and > make all operations based on the (small) folio. Sure, I will add folio_test_large check ahead and convert page->index to folio->index, and adjust the logical if ksm and swapin support large folio, thanks.