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 2C153C54E67 for ; Wed, 27 Mar 2024 06:24:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B42AC6B008A; Wed, 27 Mar 2024 02:24:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF2F36B0093; Wed, 27 Mar 2024 02:24:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BB106B0095; Wed, 27 Mar 2024 02:24:38 -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 8B1B66B008A for ; Wed, 27 Mar 2024 02:24:38 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 540B580951 for ; Wed, 27 Mar 2024 06:24:38 +0000 (UTC) X-FDA: 81941830236.20.4068B38 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf28.hostedemail.com (Postfix) with ESMTP id 4E4AFC0009 for ; Wed, 27 Mar 2024 06:24:35 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=U2BHTZN6; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711520676; 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=tAZHk3mHWnfldymCKNkgGEkgyDN6Iuv99uz52miXpvU=; b=oMHLYDM82lqOStm4knOmY73PamJGi4L3XqsbOc3Ax9o45RhspBgkvPOIuotlQtfQp2rKkW 3488omj/sN66Pq2kwoNRiwojC76aoLIvFgu74c0MByRsXd101MpWGQqwT6XsGVmKRjO7Ma L5kt4O58BoIY2rv/cPrewRT3yHUxmhw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=U2BHTZN6; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.15 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711520676; a=rsa-sha256; cv=none; b=hVjSET5pGooFEaAQ/hEA8KhpqnsGejC8uQYUbQiLJmeihtAW5rdvsQgIVqCHqsquybXyE5 WNUR9LDAboDRZCK9LJTRzgces6cA9hIuTNM2Q4469qNF5zXNVRk8P3w6ml/3yxQQEyVx4X 3sfFnGsc9zstzpoKid9zt919kCITj5I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711520675; x=1743056675; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=6BxiztpmQC7WGYYfC/J1njDyZV2TGg42X2X1s7GmlQc=; b=U2BHTZN60hLHZcDDEGpgnAI7wzW1vHYOSm2b1k2kTKuzT8cnXT5pOFyE Yz2WrATXvK5FcSwv7WX0So1ysmGi3G0bwVZsZFdd/nsV/QmeLoa5miGpS sWb00UbsHSfROg/hMLjmq2PUmtQYQ6Nw5rlilpV9m26PTYl4RYADqpTld p85LCSzti0r0NJssT/G+EwO/vPyJehzIk78ACNrx5GEhqZ5r8YlAjKsTd LVA787ls3Homcm/AmtKXxLTT0Tdb9cSVnENTsY/tOgSbUmmJ2EHEAxSP5 qIDLTNnV+TDcElfvcbZTe58iC73tfsK2OgAkhWEtd8u6kDMNsh3xiXA+V w==; X-CSE-ConnectionGUID: cnn0OVTsQTaXOWWFVROnUA== X-CSE-MsgGUID: wLka+senSV2o5H/kFHfJag== X-IronPort-AV: E=McAfee;i="6600,9927,11025"; a="10404463" X-IronPort-AV: E=Sophos;i="6.07,158,1708416000"; d="scan'208";a="10404463" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 23:24:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,158,1708416000"; d="scan'208";a="16639174" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2024 23:24:28 -0700 From: "Huang, Ying" To: Kairui Song Cc: linux-mm@kvack.org, Kairui Song , Chris Li , Minchan Kim , Barry Song , Ryan Roberts , Yu Zhao , SeongJae Park , David Hildenbrand , Yosry Ahmed , Johannes Weiner , Matthew Wilcox , Nhat Pham , Chengming Zhou , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 10/10] mm/swap: optimize synchronous swapin In-Reply-To: <20240326185032.72159-11-ryncsn@gmail.com> (Kairui Song's message of "Wed, 27 Mar 2024 02:50:32 +0800") References: <20240326185032.72159-1-ryncsn@gmail.com> <20240326185032.72159-11-ryncsn@gmail.com> Date: Wed, 27 Mar 2024 14:22:36 +0800 Message-ID: <87zfukmbwz.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: 4E4AFC0009 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4bmh56dtjhgq9xq9hsfsmzzodak5i4ft X-HE-Tag: 1711520675-587057 X-HE-Meta: U2FsdGVkX18vfie4QftaoiaojJHg934NrpDIZgTBuPTBxbb1nKs30RP93jCP5vg3+HJh1D3KN/t2QUx+fdqAwXyGvHNS8whVQaRfVKcGbLtG3abytf75REo0lIoEjDC5YfbuajQ14/AAS09xk+CYtJyo4hF1qGHybpjPhfuWu8qW/p7S9w5I+OT5d7/i6pYyAVnBG3XD2cYV4kzJe0lRK/TGVEKiqxLFzJlefNRM3G2uYKOKUNziaF3N9/bit7c3peI65zfie8bTjaHuMHIvPxwmTQm6v7+6lKzjJ5TF941Wj29D5C3dlwVMmSkYiGyj3q9AkAou9MBiNVjDl28duHAPQKjrgGIfW2dPIJhGWN273U05dCpS/EK1Mjaoj349MmO8FTGg8sgy/D/kDln64QUZ08hoNdaqz58xsJv39aQ+SI+dHwoKdTHeh+8a2jzcO7RnNuP/LhnZXF3vsINGs2gNeiii4YwfF31eK0VDSxkGgT4/oQkX+ePylklWpOd+XJkEmyxUfTYtqFESIIQhjrq9EXd0tHXZpDkVg5hEGVhQIsk4QtsiG86jnXm+TTMvj4YJHCyLZ/wUo2LbrVPaAkq79isqTbGqnyNW1x7k+W4r1vniJH3TBGBWSpCul5AJYsQc2AzVtwrBDSFNDFD8wPyksyw6FenY40Qol0y40uR6PsmlR2aZqngfaMB6iZg5hJDeV06N27M7PzsK49jXtfRitxT9IAHYZZxKLWWsQMfoAiWrGAM5eVRPD6LN5fMynYmPi61hSaN36b/A1qmWSeI1E/ig/Q/Lu3+QXwIk1WRH46+djKMzmp92U4M6rZt3won53Ja1JrEcYbTFI1BqETP7OIIaHSzljyJW3yGECN64rqHYqOEsE1O6bMkolv1CJFkoOIh3Iu+bjtUue23wlcRCNQ4BatQxrc4utqR5SxroizlY2Bn7FIXOxdxF3/wnIysDGAibl/wLBWwjZFq tR8FSR4D lPFiMt8n4wxiDunmARGIM6amXOUgVgH0kJvtTyRyWEb953JgXFzDvCauSlNd1o7QWY4wyBWB66Cby+zQt/7o2UZVgpHm4DKYdyMMiw4juKmeGlR0x0mLA4nAhYPPKuLGZV76xMvFaBYbpirlLoY/iV2Zs3Rgf2GxrVz82fhnGCdRIoUwKdbxQoDbi2RWpvD71TNtQOL+PxRYMU16Ew/G4CanfAMKcIWBNnKly3wBa7OsOOFAa2fNQYBvWn7+3bKw9d1aG 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: Kairui Song writes: > From: Kairui Song > > Interestingly the major performance overhead of synchronous is actually > from the workingset nodes update, that's because synchronous swap in If it's the major overhead, why not make it the first optimization? > keeps adding single folios into a xa_node, making the node no longer > a shadow node and have to be removed from shadow_nodes, then remove > the folio very shortly and making the node a shadow node again, > so it has to add back to the shadow_nodes. The folio is removed only if should_try_to_free_swap() returns true? > Mark synchronous swapin folio with a special bit in swap entry embedded > in folio->swap, as we still have some usable bits there. Skip workingset > node update on insertion of such folio because it will be removed very > quickly, and will trigger the update ensuring the workingset info is > eventual consensus. Is this safe? Is it possible for the shadow node to be reclaimed after the folio are added into node and before being removed? If so, we may consider some other methods. Make shadow_nodes per-cpu? > Test result of sequential swapin/out of 30G zero page on ZRAM: > > Before (us) After (us) > Swapout: 33853883 33886008 > Swapin: 38336519 32465441 (+15.4%) > Swapout (THP): 6814619 6899938 > Swapin (THP) : 38383367 33193479 (+13.6%) > [snip] -- Best Regards, Huang, Ying