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 64680C8303C for ; Fri, 11 Jul 2025 06:36:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00D506B009D; Fri, 11 Jul 2025 02:36:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F27A26B009E; Fri, 11 Jul 2025 02:36:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3D176B00A0; Fri, 11 Jul 2025 02:36:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D344D6B009D for ; Fri, 11 Jul 2025 02:36:42 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5AA741DDE53 for ; Fri, 11 Jul 2025 06:36:42 +0000 (UTC) X-FDA: 83651025444.02.0CBDC0C Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf22.hostedemail.com (Postfix) with ESMTP id 1FD14C0005 for ; Fri, 11 Jul 2025 06:36:38 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=LjXfyMI5; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf22.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752215800; a=rsa-sha256; cv=none; b=Dd8HQTdoGo5S6nmgra6ha0i418YWZyHorW2fTAb1tR//xIoA5QFT8LOoFBR8x/NAzHcCPs D8cP1quYrNQkOp/hG/avnrURlty+sBvsQQeQ+CavFFfiS8Gw0RWeKndqhzB+6s06q7n/AS 6MSg80iw9R3erWfOsjk9X3ZmV7w9XrQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=LjXfyMI5; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf22.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752215800; 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=RC+FmMVj7xVlpmIjHs3ZqgR59n3WvScw9naDpqXWnbg=; b=Xrx7XBdEKLTsUtvEOyFcZYU9rfutMfnBAbCOnPh0IDduSEzwuBJDIalgXC0zDfFYW35YUv S1fp/nZQwn+K65FhsygZ567GbTJipicXkyq+FnbFjasScetIz3GLLXKHyO021ZJbgzVr15 ifp7BzioZ53Q+jR3TlXgQHFXlyO6dwk= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1752215795; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=RC+FmMVj7xVlpmIjHs3ZqgR59n3WvScw9naDpqXWnbg=; b=LjXfyMI54nIoPi9eLzcHdicBo1kxyLoxnaDknhuYHT6xhPWh3DkVUqMluP6cZqchhMjtm+Q6oRauFHgUfz3nC5bHJDzkecc50KYfo96FwDvl+xCiv/7ZNetrU3FoTPwcC27BedNyESPKZh+HwFsrJ3wAv0LK1H6CPh3BztDGhOA= Received: from 30.74.144.131(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wifun88_1752215794 cluster:ay36) by smtp.aliyun-inc.com; Fri, 11 Jul 2025 14:36:34 +0800 Message-ID: <6d6feb41-5cdd-4591-8e19-d9c247e16fcb@linux.alibaba.com> Date: Fri, 11 Jul 2025 14:36:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 7/8] mm/shmem, swap: rework swap entry and index calculation for large swapin To: Kairui Song , linux-mm@kvack.org Cc: Andrew Morton , Hugh Dickins , Matthew Wilcox , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Barry Song , linux-kernel@vger.kernel.org References: <20250710033706.71042-1-ryncsn@gmail.com> <20250710033706.71042-8-ryncsn@gmail.com> From: Baolin Wang In-Reply-To: <20250710033706.71042-8-ryncsn@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1FD14C0005 X-Stat-Signature: en1ozn9e8opxnb9yq17eyp53gzpf6wn8 X-HE-Tag: 1752215798-297059 X-HE-Meta: U2FsdGVkX1/Cv3nQHuGLnqg/FIrT/Bboq727Df7x/OG/SjkO+lALUEbqKQqBxakrgH7Jn86MrerqSg8lyiBCtP5M5DSMltcuOowEsnCgT8CUzZnbPclDURq4YJ2fMTX6kh4w0JAyele61dwVMrrmZigk8+dbQvHkh5fQz7VOdu5ZyKEcS4K1Dmx0EoXxShPgDhjVJV6EwEpZ95H4Pxgsf8YBEposr4zYtRO2qAxPGT815U/FbA59dF8OcSlFIJcLLxRFA23H6Y/C8q9n/B378QfWVSYoTzt6nGenWEH5tDt2VyO0n/6iu16pLWGAlwEJx9PufIxKUGIMVJn+A+3B8EKDEWovmqpsUcHdjyldmTM25PkDStngBwrAJy5Uwd3phDMNJ02tFGsVGYlk32Owi2XKmZkMInf/TcJc5SCjPO6OW2g/O3EiUVDotis+4JIvuzsipucBYghdFeuAU/N596EbocYDuJxkcMbR98tKZrXLSAOfldRUYi0fxFJbSci827IxV3ne9KxrHuPIUSThbKz8o5Zq9HHqA8jTVvcOKTbYuEcT5Uz4pcnvWhPeSUX8I4xh7umyNKZq3FHlp3Rinxe7dQoKH0Wk2pJBgnUaJlYhbWc/6xzfvE9sj8VwAdPtZDifHc0gTOggUFSBYJcrt0ViUXLml0VUmub6T9IR0szR4RAqMYCy7s9QtOra28McCPScKazFqi0rH9Fm3D04BuNyTbMtvxKsfALeewP9YaSpFqEcKjMRBYRz5WUZtHlsZSjq+EVStbzFB+EP52fJFDjIyLpRdhQyKZLUStNkzMXx7EJyZyEtZ++Bif0joxGXjz7gYvv0mj4VTHtsgdKCVEIrhNU6PnTDJFTRHufJdLpxxJi/qigeDwiU7YnIfzdkPYBPUY3QULlCo6uz76ILC7JSWACg94JSMWF4fD2CH4koYy6/zFpfRCJwa6dgQEyiHvFoo7KRDbIrBURjXYb mKee1Y3c hLX18CuqyJ/ZcgZ2nHhsoosqWdK1Ymhlk8U+V5PDzJXi/mVO3Sj5J3dPc9LhyYuYMwMKkIIQxaH2Sw6Mx+UWHuGDrMT2aKKhOGjeTcxpdvRNC3H/m7UM+rgVnghlxvaXENcgWolV3xFJ9ZeGXv4qEZgfYCp3ePpsBgpmLDxfkHIHymarCFY89HEcnXWW3FE4ny1QWM6PHMw81w+lM6DBctfm/J4X9EzLJxXFtGkoOAQJeDDA7gFsg/n1FEsJ1m9qhrl+s0lYMF/RVVHguIUahhjjpsyC7pbcSkH11HtkPXEMvf56LCuxl6P5ToBkOqOzx0sWNRbyk0p8XqTxKV7npD35KPd9cvnLQfdxP 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 2025/7/10 11:37, Kairui Song wrote: > From: Kairui Song > > Instead of calculating the swap entry differently in different swapin > paths, calculate it early before the swap cache lookup and use that > for the lookup and later swapin. And after swapin have brought a folio, > simply round it down against the size of the folio. > > This is simple and effective enough to verify the swap value. A folio's > swap entry is always aligned by its size. Any kind of parallel split or > race is acceptable because the final shmem_add_to_page_cache ensures > that all entries covered by the folio are correct, and thus there > will be no data corruption. > > This also prevents false positive cache lookup. If a shmem read > request's index points to the middle of a large swap entry, > previously, shmem will try the swap cache lookup using the large swap > entry's starting value (which is the first sub swap entry of this > large entry). This will lead to false positive lookup results if only > the first few swap entries are cached but the actual requested swap > entry pointed by the index is uncached. This is not a rare event, > as swap readahead always tries to cache order 0 folios when possible. > > And this shouldn't cause any increased repeated faults. Instead, no > matter how the shmem mapping is split in parallel, as long as the > mapping still contains the right entries, the swapin will succeed. > > The final object size and stack usage are also reduced due to > simplified code: > > ./scripts/bloat-o-meter mm/shmem.o.old mm/shmem.o > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-233 (-233) > Function old new delta > shmem_swapin_folio 4040 3807 -233 > Total: Before=33152, After=32919, chg -0.70% > > Stack usage (Before vs After): > mm/shmem.c:2277:12:shmem_swapin_folio 264 static > mm/shmem.c:2277:12:shmem_swapin_folio 256 static > > And while at it, round down the index too if swap entry is round down. > The index is used either for folio reallocation or confirming the > mapping content. In either case, it should be aligned with the swap > folio. > > Signed-off-by: Kairui Song Overall, I don't see any obvious issues, but please give me some time to run some tests and then get back to you. Thanks.