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 F2134C4345F for ; Tue, 23 Apr 2024 03:20:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2629A6B007B; Mon, 22 Apr 2024 23:20:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2116F6B0083; Mon, 22 Apr 2024 23:20:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1016C6B0085; Mon, 22 Apr 2024 23:20:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E654D6B007B for ; Mon, 22 Apr 2024 23:20:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 818371A0D51 for ; Tue, 23 Apr 2024 03:20:48 +0000 (UTC) X-FDA: 82039344576.17.DB482D7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id 8AE70140023 for ; Tue, 23 Apr 2024 03:20:45 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=D3DfB22s; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713842447; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ahOv8RHRHifyUk0ox51n0lR3ydUmc3KBYtfrDe9uFDw=; b=PKhf+ekXLXl2p26OY1WbcLEqJojSepWsYxs4EnU7HQ5ovS4G2dtzp1CRoSUqK6bkO4A/Vy z+CcNWEJezodqUbgHSLHm/w4aQUHjJa0xdD9KZASp4ENuthVuY6zqElDnmDv0/og8Dp8D1 DIU3VaZmgVeP9vxjgwMbnSYow8Az7cM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=D3DfB22s; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713842447; a=rsa-sha256; cv=none; b=R8pwArV8mt1OI+BmT7SNUgTp5CzZ5+iODA5smSFlcObYLxUN/s3EDVwqdSHHptqJty+i02 HyHW7zY+ePi9u7XoU2TPimUYHbVdMgtbllZEBCOvYIFZd+QDCoPKJ/v0YbaYA9uAinqY0Z WlNC7Ftj0SXQMCgqnTmGAmcH/tjRWrg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ahOv8RHRHifyUk0ox51n0lR3ydUmc3KBYtfrDe9uFDw=; b=D3DfB22sArpzZQubmTzNVyI5BY o6Fbriu5e2GR7x+Ia4mzcXCJrV6d15JDGKP5QKjPohvpppecxXBXG8yckT/0cxCx4didyOcyK/H5U hXAm/mKp+enYKfne+boHbgUOi8ygocZppO/Ucdd9U3iq/ytQfU2U0q/A6Y4jAWqLrD+CrH1kgy/HC ebG4gdR8hJOXNlFmVnUsxxsI0nM74398582WcAQGyDsWW9Ig2gU4rY459hqCgzmrCZU8TiCKE8ZDe fj5bkxdwpHxnDc4XARp1gAmCMnOK20ruCJqOZdEV0TZ9ZPQUPT4vrBikwtZHD0nX4oyh5FuLX14uj f+smxCLg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rz6hp-0000000FVEl-2lAA; Tue, 23 Apr 2024 03:20:29 +0000 Date: Tue, 23 Apr 2024 04:20:29 +0100 From: Matthew Wilcox To: "Huang, Ying" Cc: Kairui Song , linux-mm@kvack.org, Kairui Song , Andrew Morton , Chris Li , Barry Song , Ryan Roberts , Neil Brown , Minchan Kim , Hugh Dickins , David Hildenbrand , Yosry Ahmed , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/8] mm/swap: optimize swap cache search space Message-ID: References: <20240417160842.76665-1-ryncsn@gmail.com> <87zftlx25p.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zftlx25p.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Queue-Id: 8AE70140023 X-Stat-Signature: 39c7usq35r7f1rk8isdtguw7ykyhgsmr X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1713842445-101419 X-HE-Meta: U2FsdGVkX1+X3q0HTqluwZn/HgjTUWEFILBTSoSlKkRoZby2amQLVdEKZHZCWeQtfcB8vBpVxh6PfKYvUu8G+Wvh2PSKxXInBgCxWgdbcQ6L3ZVp8syZJ7mSHXCo4u+Mm8wxm0BvKXBq4665SOKBfgP0MjHpS/OibCOq1RFinhJaRgQOxwoTIlphhovy44D8azYAsAfd36jaLKMycJrgfy45rbhtoGu2z736IlhNbD2r4UVwgnmHz91VApjU0ZjUGMKr1csQfYr0KXDEV9NzvVnrKLdZQFnc3ahEoAxtBsoZMaZN9JCraHgYXfrNRyL+WM0jfjcAIgS4gMeIna6YfVPR3FUhqz0CZuLfnVezQYz+clQ7asZdYkSdC33rDVawD61mm47bWzBDhN4yeir5Tr0sgLBFucN1DeyzaSRLnlxrpSduz8YU3R/wHZXk203oqs6Cd/3577ycdUxMXn6lp8K2+MOkGy+A+pdJLlmcYKpLGm7Ng3t4k6PtRg5juMkl9h3uYagEINpxVTwJS/aTsURbRFU7mAlfKuaErJdhAnvCZTxNx6uvnQa8o63V93EKacm+80R7KRsoCJ7OAOdrAkzfSUL1ikiccP1z5GTgWtBu/e7/bpFjmf/XLVIjF8grJ11ckibjQmW9nVBP1xCCFhFVwyWxzTIfuWvoyRpdvpJLIkNfIsorKfM9pc3v3zCKH/C/XraT+pVKWpSQtZ92/mKx921aNtLfMoFkXGaj6xeAQHC57eD4kuA4ioxZbOA/8/xcbLcgw5jvGtSXI9tIO27bojCMjC93DtQ5jX2A2A7rDXQVIKPfLeEs1rIxQqPYy6B15KqjC5lSfQKJhp5Piw== 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 Mon, Apr 22, 2024 at 03:54:58PM +0800, Huang, Ying wrote: > Is it possible to add "start_offset" support in xarray, so "index" > will subtract "start_offset" before looking up / inserting? We kind of have that with XA_FLAGS_ZERO_BUSY which is used for XA_FLAGS_ALLOC1. But that's just one bit for the entry at 0. We could generalise it, but then we'd have to store that somewhere and there's no obvious good place to store it that wouldn't enlarge struct xarray, which I'd be reluctant to do. > Is it possible to use multiple range locks to protect one xarray to > improve the lock scalability? This is why we have multiple "struct > address_space" for one swap device. And, we may have same lock > contention issue for large files too. It's something I've considered. The issue is search marks. If we delete an entry, we may have to walk all the way up the xarray clearing bits as we go and I'd rather not grab a lock at each level. There's a convenient 4 byte hole between nr_values and parent where we could put it. Oh, another issue is that we use i_pages.xa_lock to synchronise address_space.nrpages, so I'm not sure that a per-node lock will help. But I'm conscious that there are workloads which show contention on xa_lock as their limiting factor, so I'm open to ideas to improve all these things.