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 AABC1C4345F for ; Mon, 22 Apr 2024 07:56:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 455556B00A6; Mon, 22 Apr 2024 03:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 406056B00A7; Mon, 22 Apr 2024 03:56:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F4686B00A8; Mon, 22 Apr 2024 03:56:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0F9756B00A6 for ; Mon, 22 Apr 2024 03:56:58 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B35B9A0B61 for ; Mon, 22 Apr 2024 07:56:57 +0000 (UTC) X-FDA: 82036411674.30.573A686 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf09.hostedemail.com (Postfix) with ESMTP id 851B8140017 for ; Mon, 22 Apr 2024 07:56:55 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LMY8TBoE; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 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=1713772615; 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=XO1EheGQN5yO5gbhsXOAuZC9q9owcu58KuEEZG7x2S8=; b=mDguRuGt+nqo8qxrk2Fl6iyhrL7DkgstecA2VWt5wT9uki+jY5lBoP/xJnAgDK+4hGKoL/ S7NJLTp1ZZYWZwAM0ZYNkDwEZqEy2kexaz4Y5PDu9Cbeo/hC2A/i2yQ04TWkgsYByOxX6y vh1/pPura7BeTqAmzOutBOYGRsQK1pw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LMY8TBoE; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 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=1713772615; a=rsa-sha256; cv=none; b=TnN4QtUQQmJrmtoYKH0Vr/h7qBSQRykvWfhTh5bS4y3dTL/IQrqkn3FmN9UwPCC7KuXZIk LBciqELmG+a69SFcil90smwiSytsSI+WZrIrZiqUvRItNHTbhTobYwdbMTzLIdrGa9tszG +YJyU2zsAo48npoJYAd/eJ5TGk4mcMc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713772615; x=1745308615; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=ReeVKZSFAA2TgPLpJsgH6vWWoeK6ccoz8J1wehOOJc4=; b=LMY8TBoE0Puo19VmQ+zYyWZ52nLderHzXhM8lUVgOJL/WW6KV9d0iCtL b5nqxMekiWFMJfwLP5bp6IgyNe4AJacmIqkvzjCAAOMJErRnmKQkkqCa1 ro1B1+3lIKyi/4YvTFWyPNRQZXxDPw8qMu68s/H/9QDjXuKvcmRpHeIMm LMdakky0Aj2EI9gLLwukrSMKbmC1JmyauDcR7EaxS3YHB96rgubdXS6YM 5IMKwu2qjfzF+M8nHFuXwdCm3jdhujsRMJxG4qaswmh2IuMvn9+X2YtY+ N3yrKvlytkBxG8s2eLdKq2CKXwD6HvnBbW9HRAjbLrP4yDXPNuxQS5unG g==; X-CSE-ConnectionGUID: ODWco5uLTUGMzKP9SeWgrg== X-CSE-MsgGUID: w2phk/W5S9yLmWcVPOWDfQ== X-IronPort-AV: E=McAfee;i="6600,9927,11051"; a="20437644" X-IronPort-AV: E=Sophos;i="6.07,220,1708416000"; d="scan'208";a="20437644" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2024 00:56:53 -0700 X-CSE-ConnectionGUID: MMO+r1HCTdmStEKaAQMcDw== X-CSE-MsgGUID: svSs77+HQy2ghrhGboEg2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,220,1708416000"; d="scan'208";a="24015095" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2024 00:56:50 -0700 From: "Huang, Ying" To: Kairui Song , Matthew Wilcox Cc: 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: <20240417160842.76665-1-ryncsn@gmail.com> (Kairui Song's message of "Thu, 18 Apr 2024 00:08:34 +0800") References: <20240417160842.76665-1-ryncsn@gmail.com> Date: Mon, 22 Apr 2024 15:54:58 +0800 Message-ID: <87zftlx25p.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-Rspamd-Queue-Id: 851B8140017 X-Stat-Signature: atsgq49p696pctg7bcqoyiboz6bqh8wa X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1713772615-137839 X-HE-Meta: U2FsdGVkX1/D1BhXctVDbklnRnmuoq+7wDt+lA1U4D/XQDobVqMSZ+Ur6wHNBKKTV5cWjsZY98xnPhQxuqjtdjjhFc5ctcBop3K8n8R0ZyvFd+zcTlpJz3uYwtgjYKbcBQEOxukZDiEnDqIUcgC5DKT6Urv9y4tgZtnpHkCrjsjKt8KwlKJTJn1jrHguI5+hdyY5eqMl1cxoADVGKHcAZTybVAwyGMZ/G2FM4/vTLWBm9HZYvo/6u58ECwYF55SlXKpFkd+dgVzWjeh8oLdBNAgMV8vk1jVROPPLjVXpX5KiXoCwAEVnp1sQx7PHDEZdhqulYShd1Z9zwl6kvvIpNwTsk0BIiL2EymDCFUV+0QKcnSUTpydlaU7BADdEYkzLXiVW+xRLqN06Xmj1eG2cGOV9HMrgK2LdXOZ8o42YI/rpESO1PSVcVC0u4zSSv0qpJSjBJHpfZS6hn2R3B0mfDibNaxxkEz+GTF3F748CzOkDfa5T8jaKFDC2Pp5ljsrP3fuChYlGIfAmow/WPbYG4KKAQrieaWp+jxq9HOpxVDwCO4ywEb0MkEMy9WZWjeg7Haj0Y1TWwCVLsV0e7Dpxkahp/uX8+hqqK8hqWI1ZWAJpzt0s8y5A0ZFXGJMfEjCeWsYiUuFJppLmJjYjKWlzrRw+KW/sMX5eNUInmqnq35w7x7BqtK7V8jk+SdJabIlmk0VLp+jCy2X7rUHVZqKQT0eQmI2yFN9bbLIUbfQRq4UPXqvDY2YQTB8+zpkJhFBSu1JvbAwJvU1AyFq6C/45wK7Q5n+h6blJIF2MCv6v0BXPdqzVrZOOJyIKIXyBKGGhxcKgSELKuXG6vlxLJ2vQjtvivKkt6Sysh3m9VEFU3ivay4g+oC47I048+4qZ53lVacUOiKfVEkFVgSdS/QcQ3juq2KqO8NF3fcAiSWZHVccfkP16c0EgYs+RVHMQWLoJ92eYalEvk+YIP+N4/Qd FUnatMxB TED6QfSiT+Q5poL8IAFr0zGzbJrcWICpZwR7qZWDl9UohP31/l4OWSZ/7+RMZaTSwiV9SzFaVq1cFqLWOYiqKbEfHQYlyD2km0nAuerVMBKWu9mk5CtZoIpnbMzb1eS0+4mSGwAlZFTiT0pYNADFfz8y2IkUT/jD6MAZgKhVeyuuGJJzzzPjkFoFw/MKhltYqXKcg7aeiW2Ut2VO8V6mPPo1DpDr/3Mo6oKk9TyiUZHGBhihj4YuyMAJixouhOUrL1Yb1 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, Kairui, Kairui Song writes: > From: Kairui Song > > Currently we use one swap_address_space for every 64M chunk to reduce lock > contention, this is like having a set of smaller swap files inside one > big swap file. But when doing swap cache look up or insert, we are > still using the offset of the whole large swap file. 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 we are using the offset from the whole swap file, so 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. In general, I think that it makes sense to reduce the depth of the xarray. One concern is that IIUC we make swap cache behaves like file cache if possible. And your change makes swap cache and file cache diverge more. Is it possible for us to keep them similar? For example, Is it possible to return the offset inside 64M range in __page_file_index() (maybe rename it)? Is it possible to add "start_offset" support in xarray, so "index" will subtract "start_offset" before looking up / inserting? 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. I haven't look at the code in details. So, my idea may not make sense at all. If so, sorry about that. Hi, Matthew, Can you teach me on this too? -- Best Regards, Huang, Ying