Message ID | 20240510114747.21548-1-ryncsn@gmail.com (mailing list archive) |
---|---|
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 B6B08C25B5F for <linux-mm@archiver.kernel.org>; Fri, 10 May 2024 11:49:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CBF76B00BE; Fri, 10 May 2024 07:49:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47BD56B00BF; Fri, 10 May 2024 07:49:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 343046B00C0; Fri, 10 May 2024 07:49:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 19DDE6B00BE for <linux-mm@kvack.org>; Fri, 10 May 2024 07:49:54 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C87BBA17CF for <linux-mm@kvack.org>; Fri, 10 May 2024 11:49:53 +0000 (UTC) X-FDA: 82102317066.30.9D529CF Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf02.hostedemail.com (Postfix) with ESMTP id 1B9DE80007 for <linux-mm@kvack.org>; Fri, 10 May 2024 11:49:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aZ2pODzC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715341791; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=JEJ+bXS2uoPYXUBSHd6/sAtybdUy2Iom+XBD9eN3z9M=; b=MTvBdoZNqyB31jHBqNxvKb3xDPDkgnzLCiPm588ozcYnxaAGY9NGiUHytH15pj/c4k8aDy 6Y9kbzMPyClhJd2Hvx2zvMaG+F9w5d2LXpGo6pKGz7iSkAYRTtWCIUMt49dYA4Xq/Hg39T EgZjEt3GBIA1qiObpFk5YkWnnXmddIg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715341791; a=rsa-sha256; cv=none; b=MJUA/36iUNNOOnY/ZmhxNIb4oQ/Csu9I+BR8q353cVd/24KeOYL3oPje/7yoxHZIbQFjla XzayUeUOf+7TXxearRifFoWIvl31p6xOQQC2nR+nca88UtB8lUE2t56OqlT3e8r/AT4wiI boKRwoIh1MOfdATFqqaKzm7C6SZeWrY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aZ2pODzC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=ryncsn@gmail.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1ec69e3dbcfso16057065ad.0 for <linux-mm@kvack.org>; Fri, 10 May 2024 04:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715341789; x=1715946589; darn=kvack.org; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=JEJ+bXS2uoPYXUBSHd6/sAtybdUy2Iom+XBD9eN3z9M=; b=aZ2pODzCMX627+XoHiqiqOkOdMKLfdSZvUa+OJmGlyOPAHUxfSR6oSatfw99Cv1BVo INpiJadov424DatcWE4AA1f9O7KYHJEwx2lAVQc00dPcGHRMNtaOPz/yQ9X7BCsNc1UV C6GAyE7CSuvhQdquXxY7W/hmeISyv/udAvLdeRGdN6PuYytUABcZTbY+1pj4msAaBEmL e1ObmGweWQVFnghhFhx7ErJWVLNumHaZVQ4iYCoDUxQwuhbcyGgIFodsynGX4YZCyRsr ps4J1Wm8T45crRRDLp4EWm0ZyzwydqnEUuWFs7nM/rzVS6Mhee3BoDb+uBANg0xjtAHO kKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715341789; x=1715946589; h=content-transfer-encoding:mime-version:reply-to:message-id:date :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JEJ+bXS2uoPYXUBSHd6/sAtybdUy2Iom+XBD9eN3z9M=; b=NC7OLu+VcW6HvK2oyymyZlt6tTjVgElsnJJfpjeYMSErVxFlwHLQlMGSOpxSRvPypV o/zKH6ONKay2iCgsGcQiINmN+aUGrvrqMTDALf/AYckvkr2hDF6FM9+WOc/KsufNLnuz j1+SyUh5wGQ1X10rHR4fLRDehrEj980ZSOn8wyQWfKkJYPVT8zX0MSO7t8khyWiA7ouR 5gHn0fcK8LID7FSNy1KUtqLNMEDg+NJib3jp2d7itfr+tn2YAHkrK1fjUMRefi+B0rOS rf0n6Cl/5OlR0XhEnZObAFpJ7k2SDiwY4Y0RMG933Qq+an5zo7LBzBpWrdVsDUcvG7Sc 4CMQ== X-Gm-Message-State: AOJu0Yx8XDxSWpxtewH+aUC0N8Hw7njkkPJAGiMv/WC+yrXSForweHoi z8c/EAh+jdEWp4mc7zFFY3aPEYBVNAMDQEoHWtV2o3jxhCD+/zuqOJx2+/BJstp+Cg== X-Google-Smtp-Source: AGHT+IEk0nQ6WTWqUQUjcvmxyBNrGBVqk/JdgpWP0HR3+Dxk00t5rJln8ChmuQQhselkib7wiz56DA== X-Received: by 2002:a17:902:d58a:b0:1ec:a65a:e4ad with SMTP id d9443c01a7336-1ef44059ea7mr29149025ad.66.1715341789314; Fri, 10 May 2024 04:49:49 -0700 (PDT) Received: from KASONG-MC4.tencent.com ([43.132.141.20]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0c134155sm30183825ad.231.2024.05.10.04.49.45 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 10 May 2024 04:49:48 -0700 (PDT) From: Kairui Song <ryncsn@gmail.com> To: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org>, "Huang, Ying" <ying.huang@intel.com>, Matthew Wilcox <willy@infradead.org>, Chris Li <chrisl@kernel.org>, Barry Song <v-songbaohua@oppo.com>, Ryan Roberts <ryan.roberts@arm.com>, Neil Brown <neilb@suse.de>, Minchan Kim <minchan@kernel.org>, David Hildenbrand <david@redhat.com>, Hugh Dickins <hughd@google.com>, Yosry Ahmed <yosryahmed@google.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Kairui Song <kasong@tencent.com> Subject: [PATCH v5 00/12] mm/swap: clean up and optimize swap cache index Date: Fri, 10 May 2024 19:47:35 +0800 Message-ID: <20240510114747.21548-1-ryncsn@gmail.com> X-Mailer: git-send-email 2.45.0 Reply-To: Kairui Song <kasong@tencent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1B9DE80007 X-Stat-Signature: ma81jw84azeffnwe11wqcojbd4iskrmk X-Rspam-User: X-HE-Tag: 1715341790-455339 X-HE-Meta: U2FsdGVkX19mEcI9Au2SLh3dSeuXblOOKB/jZVGfUbaq9jpY1mKmSP0QblIC4cYyBn6GbN4djQCgsVGA8Zq/67YCVKEFJQwrkt9D2ebyUE8/Oj2Y2wDs6w/94bpjFp3cNXaxjnXuO2UW12Ww/+bStxKZmKOPh78GUO3zAf7OEx/NOyzHOLCUJmX9fcOMDNaMHwrK5OGISgCJVtTHErxncwNUPgHDGjhbVDHTK3RPH2PEbzQqxt89c95Y3U/8eOqwyDUvuQPN3ya/xHD6GWZK2pJy5LP87GLEb4sCAM2OKtbsxPc5ztdqTD7Aa4nAgEwrec8b1+ShfRLqh982tBEd6GfjyksxjZP1pY0i3g9MBx7Y3DZjllQgDfRLUbDAhOoEK6OyzF+tmN5j7nfunYlN3kOO99ZDc0cg7PMbvdkKxi2eDXZzWYcjSCIL2fwx/wxbVhOSjVQwVFhuVn/VVTr1ky03hK7VHlzSUezwJ3KFxJGY3ATJEwk1/QsXKuUdY5rCIul/5KW0MJQdmpP4yqi2vfUMMgvgHz+3KMFUU0Cv2C2kxzb+BcmEYfEtEcLTkwmRY9rzjyJu41NxU4l2Pg5vivnbQuk5yVRjVH1jMyoXC1vOUVVbQ1eyirTk0O0DJw//H5enjDylqldvdEJa8RU1RN4UBgRQg2JtZOfMQLaAFd3lqVRzCa51A7V1FYi62APKqrt81FLBqb7pKrEnDf/NWJtrldOeDfHIDp1tmziopTQQcDTjx3GcbZn5BsZkjNJ5aBJVYwupT/bvRq0ik2yOlK1timn8Q3LNInA6v5LR4ciS6AwZq/QD4fSbZW9ecLIVL+LMGQyXdhJaQtBTt/BIZ6JptDgReYpRb9oWMhhaQiQ7tvzeImTmrVSHQayFgXryJGkBcXBqJVvPw3hFc8qiPjzhBPgLQrVPELRzZ6PH9V2C9nC/KCbg7qJa19cz13hnXa43fAuzWGpZETolMOr 3JvQc76l j+T/V7OrHLLXf2/A36LtXA4tzAh2msTFVn0K31JREw43/coAWhwjkLgSlPWcZ7z1APDViHm97LEa9IqqRfWCk1G4Yutcfi4b60Q+Il9pFxXbZEYQw02PZjgJ1BMOKMXui2ooG4gy/alDwRl9bzWjJexi2n5No7pYHqy+xIZtU1tEy5aZyG7kYMt15q+FHGb1KoCzf3qmv2DDLnQls67IA9zxNe34/l0P6QNwpHrc5HkUeBKHWjsjLOXcxjPfC3vqxeN55ZnUMU0sZ+b1DuyGgPf9ptDLXkNNqWN7HU3O7KJMDzOhBiZZMpWf3l8I+1t7dm1ID5W7FOrtd5MT5Q8WhTbiOPDx5cr9lV5orho20y7rxdEMthyaqvVEsA9ekaifN+E3W9pr7yz26xxDZrd7ml2/W+7C9TsQGjgzP3shXYG21IbD7GYsBoTHaXJCPS0gHsVrB6cHX5Q60thxAN+JHgbfO8S4xF37Mv7ENfVOrGB7E6f+MY7EMyrDPFr5oC+Wu4MetopWV3Wdr5Vg32qkqBFDQdWXOMmnR9DTV2REym6rzbRIYYRAwMVcBYqd+RVbw9AI0FyeGBX//MPukc20Q9mhkpUzSZWeMibC07Z2kIWrRM/d44IjLU8DnSrt72+jx6pUxeapZsvmoe1H3zin29k9aZ2DxUpbn7hFZjd2qzXecWbFSQ/swp2ZmJIOMBqxLqKOihPfX/yJ8abtbM0auFatd0NCAJlEtiDZOVj7L7YL65+iVRyL3uFZntmoANZAhS64orYKTIdCvFLA= 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
mm/swap: clean up and optimize swap cache index
|
expand
|
From: Kairui Song <kasong@tencent.com> This is based on latest mm-unstable. Patch 1/12 is not needed if f2fs converted .readahead to use folio, I included it for easier test and review. Currently we use one swap_address_space for every 64M chunk to reduce lock contention, this is like having a set of smaller files inside a swap device. But when doing swap cache look up or insert, we are still using the offset of the whole large swap device. This is OK for correctness, as the offset (key) is unique. But Xarray is specially optimized for small indexes, it creates the redix tree levels lazily to be just enough to fit the largest key stored in one Xarray. So we are wasting tree nodes unnecessarily. For 64M chunk it should only take at most 3 level to contain everything. But if we are using the offset from the whole swap device, the offset (key) value will be way beyond 64M, and so will the tree level. Optimize this by reduce the swap cache search space into 64M scope. Test with `time memhog 128G` inside a 8G memcg using 128G swap (ramdisk with SWP_SYNCHRONOUS_IO dropped, tested 3 times, results are stable. The test result is similar but the improvement is smaller if SWP_SYNCHRONOUS_IO is enabled, as swap out path can never skip swap cache): Before: 6.07user 250.74system 4:17.26elapsed 99%CPU (0avgtext+0avgdata 8373376maxresident)k 0inputs+0outputs (55major+33555018minor)pagefaults 0swaps After (+1.8% faster): 6.08user 246.09system 4:12.58elapsed 99%CPU (0avgtext+0avgdata 8373248maxresident)k 0inputs+0outputs (54major+33555027minor)pagefaults 0swaps Similar result with MySQL and sysbench using swap: Before: 94055.61 qps After (+0.8% faster): 94834.91 qps There is alse a very slight drop of radix tree node slab usage: Before: 303952K After: 302224K For this series: There are multiple places that expect mixed type of pages (page cache or swap cache), eg. migration, huge memory split; There are four helpers for that: - page_index - page_file_offset - folio_index - folio_file_pos To keep the code clean and compatible, this series first cleaned up usage of them. page_file_offset and folio_file_pos are historical helpes that can be simply dropped after clean up. And page_index can be all converted to folio_index or folio->index. Then introduce two new helpers swap_cache_index and swap_dev_pos for swap. Replace swp_offset with swap_cache_index when used to retrieve folio from swap cache, and use swap_dev_pos when needed to retrieve the device position of a swap entry. This way, swap_cache_index can return the optimized value with no compatibility issue. The result is better performance and reduced LOC. Idealy, in the future, we may want to reduce SWAP_ADDRESS_SPACE_SHIFT from 14 to 12: Default Xarray chunk offset is 6, so we have 3 level trees instead of 2 level trees just for 2 extra bits. But swap cache is based on address_space struct, with 4 times more metadata sparsely distributed in memory it waste more cacheline, the performance gain from this series is almost canceled according to my test. So first, just have a cleaner seperation of offsets and smaller search space. Patch 1/12 - 11/12: Clean up usage of above helpers. Patch 12/12: Apply the optmization. V4: https://lore.kernel.org/all/20240502084609.28376-1-ryncsn@gmail.com/ Update from V4: - Collect Review-by and Acked-by. - Fix a leftover error in commit message found by [David Hildenbrand]. - A few code clean up for better readability [Huang, Ying] V3: https://lore.kernel.org/all/20240429190500.30979-1-ryncsn@gmail.com/ Update from V3: - Help remove a redundant loop in nilfs2 [Matthew Wilcox] - Update commit message, use the term swap device instead of swap file to avoid confusion [Huang, Ying] - Add more details in commit message about folio_file_pos usage in NFS. - Fix a shadow leak in clear_shadow_from_swap_cache. V2: https://lore.kernel.org/linux-mm/20240423170339.54131-1-ryncsn@gmail.com/ Update from V2: - Clean up usage of page_file_offset and folio_file_pos [Matthew Wilcox] https://lore.kernel.org/linux-mm/ZiiFHTwgu8FGio1k@casper.infradead.org/ - Use folio in nilfs_bmap_data_get_key [Ryusuke Konishi] V1: https://lore.kernel.org/all/20240417160842.76665-1-ryncsn@gmail.com/ Update from V1: - Convert more users to use folio directly when possible [Matthew Wilcox] - Rename swap_file_pos to swap_dev_pos [Huang, Ying] - Update comments and commit message. - Adjust headers and add dummy function to fix build error. This series is part of effort to reduce swap cache overhead, and ultimately remove SWP_SYNCHRONOUS_IO and unify swap cache usage as proposed before: https://lore.kernel.org/lkml/20240326185032.72159-1-ryncsn@gmail.com/ Kairui Song (12): f2fs: drop usage of page_index nilfs2: drop usage of page_index ceph: drop usage of page_index NFS: remove nfs_page_lengthg and usage of page_index cifs: drop usage of page_file_offset afs: drop usage of folio_file_pos netfs: drop usage of folio_file_pos nfs: drop usage of folio_file_pos mm/swap: get the swap device offset directly mm: remove page_file_offset and folio_file_pos mm: drop page_index and simplify folio_index mm/swap: reduce swap cache search space fs/afs/dir.c | 6 +++--- fs/afs/dir_edit.c | 4 ++-- fs/ceph/dir.c | 2 +- fs/ceph/inode.c | 2 +- fs/f2fs/data.c | 2 +- fs/netfs/buffered_read.c | 4 ++-- fs/netfs/buffered_write.c | 2 +- fs/nfs/file.c | 2 +- fs/nfs/internal.h | 19 ------------------- fs/nfs/nfstrace.h | 4 ++-- fs/nfs/write.c | 6 +++--- fs/nilfs2/bmap.c | 10 ++-------- fs/smb/client/file.c | 2 +- include/linux/mm.h | 13 ------------- include/linux/pagemap.h | 25 ++++--------------------- mm/huge_memory.c | 2 +- mm/memcontrol.c | 2 +- mm/mincore.c | 2 +- mm/page_io.c | 6 +++--- mm/shmem.c | 2 +- mm/swap.h | 24 ++++++++++++++++++++++++ mm/swap_state.c | 17 +++++++++-------- mm/swapfile.c | 11 +++++------ 23 files changed, 69 insertions(+), 100 deletions(-)