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 EEF34C04FFE for ; Wed, 24 Apr 2024 02:26:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DA406B01AE; Tue, 23 Apr 2024 22:26:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58A616B01B1; Tue, 23 Apr 2024 22:26:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 479136B01B3; Tue, 23 Apr 2024 22:26:08 -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 2EF496B01AE for ; Tue, 23 Apr 2024 22:26:08 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D976E40591 for ; Wed, 24 Apr 2024 02:26:07 +0000 (UTC) X-FDA: 82042835574.21.4853E19 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by imf02.hostedemail.com (Postfix) with ESMTP id B2D0B80003 for ; Wed, 24 Apr 2024 02:26:04 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hqF5gspg; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713925565; 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=2fPGdNEF6ZcLFLJucgqDO9JWuglkMQauq2Y0Ib4nxMc=; b=LbZAbN4+uiOHZA4HZ+vZU/09cZYe/2Jz2I3oUrnzVDVAOc2OWZFhCCfIX09dJ4P3ZHz6OM Gb7gSrH4qh5ljM7UtlnQF6A44uEMlWk1mFwxYj7cegH2nVINibnWxGvfPTegEPQTYerPFb JSJnFyApy58b7LzBr5cZnKlrSnfSm68= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hqF5gspg; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713925565; a=rsa-sha256; cv=none; b=fwh557JJcDa0Pfq77gBx3SC5qpU6PT06U2UzZF2JtAdomqKENaQa78UoIN8LE1pey7yuib 2mlBAD3l7VeOmdfIBNN1xGLJ/E3D5yxiDGKQ6Iorxl2qMBmZE1GnCClTelqtorLFOXwVAF zcXsmXPlm2jpGhUMAVF9xOyzKJYy8r4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713925565; x=1745461565; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=QmPQF7eOoPT8Nnn8OjXFg1nFy1plktJnigngENo2NvY=; b=hqF5gspg4YynjBj36XAkd2XQW4gDvkjnb4lL/smMqrzmpv1ZxDQcpPeA LIOagV4Z0iumpdCVgEWW+fUXdvXM9Xqw+DXlgG6qwByJ6vjRooA3ggwPQ fNqEapdu2AsUl17fndGBHo+1wLF4Ad0RbCPA9XuOXobcO3LI/6ZDmkkyl qpzrxkAOBrMga+7sLYxbpQ7LX82PIbzT3Vwl7YyhQt7t4/sjOtP7yRy7X Vkk5X2Io1+4IlTXLCiq9IkXegdAcA/VNMfwXQqj+LtLv3ybLQQcXaksin xTUlJ9ztlDEor9c52f3JRb99L0ad53gdEIWqxfWPevTwHhY3c+ZOieaFB g==; X-CSE-ConnectionGUID: POMf/0mNR52ikVJBWWssVg== X-CSE-MsgGUID: UaopM19tS4qjvOcvdoGJbQ== X-IronPort-AV: E=McAfee;i="6600,9927,11053"; a="27051301" X-IronPort-AV: E=Sophos;i="6.07,222,1708416000"; d="scan'208";a="27051301" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2024 19:25:58 -0700 X-CSE-ConnectionGUID: VvU8Xw05S0qwtinn4bSQ/g== X-CSE-MsgGUID: XqJH75ReSsebrfkSkF2Hyg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,222,1708416000"; d="scan'208";a="29039432" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2024 19:25:53 -0700 From: "Huang, Ying" To: Matthew Wilcox 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 In-Reply-To: (Matthew Wilcox's message of "Tue, 23 Apr 2024 04:20:29 +0100") References: <20240417160842.76665-1-ryncsn@gmail.com> <87zftlx25p.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 24 Apr 2024 10:24:01 +0800 Message-ID: <87o79zsdku.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: c6spucwz7tzpw8xyakxdisabpsfgqe46 X-Rspamd-Queue-Id: B2D0B80003 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1713925564-722757 X-HE-Meta: U2FsdGVkX1+5qI6QGnAPW8Fqd39wzJij/vhJrC/FS38QML2zNEZiSEk0iKgYTRi0sfO+LCpgb+5Qt14nlfstzi1TxQwI5iiWM5KNkRvAHld5VbqVoDfOMmuS9H3hpMRtg5RvYBwG+9lmUjI2znSx8RKImplZW+ZCzAJ4PiDazeNwztQE78I41xlYwI0jafwaD09I/g3Xbcjs6grHd4l3nl4kzomktojwO62B0f+N0GqeoJ7NohAtGtnFb0EAtbbuLcyOGQeg7MRwj2RHGkxPqxc2sfxDplGvU8u1bfRFHQsBIeKHGDTamOA0dxpsVolPDGigmCotlNDyqV2xcdA7UJk1vrDHa0zGKs7Pf3RHLRRklR8YbovIflSDBHcrtfk8rkDhyBDW1XXu/KdAWodVW8AU0kmcMX5lTysIpDrMkLAmdlAbNHr43d3lky5Z3ZgeEDSpfNT/tUZdw2kU2jDu9CJ+Fl6DM30wkD0RxxCRMeeiogY/q3XK6/QZYhj5HKeuGLUFJqeLf/WAvB21bUhkjApfOidJHdDb3di+sLVU/1IjfJxsGerFeQqhCfdmUW0GEl/ekX57JQ7oLgl1P72BRbRSvs2VqmYtaOXxuNeS4p0lb+Ja0wa2D1u+vuR73WFsjK0VEdIyTms1vLX11sLL89i6tbfjCXPFnmYupabaLyx72OknzA+P0dTjScnZQmrQQzz7lH8JyZUiEu1zmpiyOxaQRUF1EP2bjdP4pt9vYueZCg7cspwT6+j5qViatgmHIchHXS+WCWKK8da9IkP144X8Deaf8iSf1PSVQzWUGywlYE8HzEAcqA6lDeDyb6367ExZuS5vAAdnx1RJwnEWmnm3yuG9i5CsMaj6kTKsL00sSz/yXigt9p/Wxq+8vHvqnp9v4A1Kij0GYsloJ63qol7h5jttGep0VwKYcsYCkQMEXKR3GgDT16/so0wiQ/rOQvHQMXBE9kNTZH4+sua qdTZVBkh QTt7RUpPfasPC5ToGojZ3tTTWxRNkR5ofyMTcMXxuqV5tggGY6FgEUzt9PBR2jjqKdgGRvmE+ilNYGa2bCzO/5BbQIs7QfqzXUlzIp/2YZeOiiMuS2nI35iZojipgWjOlWuGS5O49aOpQWOTOxaItOnqG+L+fbf5g2eZ0Rwcy7gkKpFxtSHxXePzPdKTZ5QZ/KKgPCpOomsez3O8= 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: Hi, Matthew, Matthew Wilcox writes: > 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. Thanks for looking at this. > 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. I have no idea so far because my very limited knowledge about xarray. -- Best Regards, Huang, Ying