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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C779CC433DB for ; Fri, 19 Mar 2021 06:24:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CAAE64F69 for ; Fri, 19 Mar 2021 06:24:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CAAE64F69 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C16596B006E; Fri, 19 Mar 2021 02:24:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA00F6B0071; Fri, 19 Mar 2021 02:24:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3FE86B0072; Fri, 19 Mar 2021 02:24:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id 885D96B006E for ; Fri, 19 Mar 2021 02:24:37 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 30EB38122 for ; Fri, 19 Mar 2021 06:24:37 +0000 (UTC) X-FDA: 77935634994.27.75E9AC2 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf13.hostedemail.com (Postfix) with ESMTP id 0BF5FE0011D2 for ; Fri, 19 Mar 2021 06:24:35 +0000 (UTC) IronPort-SDR: LqUAHkxe/shalESdtFeECAO5Hd35Nmt+DP1+8ucQBDlFfWA9MvUsl7KjeAEQdYzZXvQdjg+kaW gxu4uLMuaLDA== X-IronPort-AV: E=McAfee;i="6000,8403,9927"; a="169763727" X-IronPort-AV: E=Sophos;i="5.81,261,1610438400"; d="scan'208";a="169763727" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2021 23:24:34 -0700 IronPort-SDR: AMJHAwueOU8cACJZ+XMdN9tXrePVt5vh+bW10zl4XqSuwpjQoYUH3iEkqYtaLQ9WHoync+cZC1 AxVg8D3KFwvQ== X-IronPort-AV: E=Sophos;i="5.81,261,1610438400"; d="scan'208";a="406664830" Received: from unknown (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2021 23:24:33 -0700 From: "Huang, Ying" To: Matthew Wilcox Cc: linux-mm@kvack.org Subject: Re: page_mapping vs page_file_mapping for swap cache pages References: <20210318210147.GV3420@casper.infradead.org> Date: Fri, 19 Mar 2021 14:24:31 +0800 In-Reply-To: <20210318210147.GV3420@casper.infradead.org> (Matthew Wilcox's message of "Thu, 18 Mar 2021 21:01:47 +0000") Message-ID: <87k0q3y82o.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: 7dqyge7qty97itfk86uj434ez3wuqfqn X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0BF5FE0011D2 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mga17.intel.com; client-ip=192.55.52.151 X-HE-DKIM-Result: none/none X-HE-Tag: 1616135075-684263 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: Matthew Wilcox writes: > If we call page_mapping(page) and PageSwapCache is true, we do this: > > if (unlikely(PageSwapCache(page))) { > swp_entry_t entry; > > entry.val = page_private(page); > return swap_address_space(entry); > } > > #define swap_address_space(entry) \ > (&swapper_spaces[swp_type(entry)][swp_offset(entry) \ > >> SWAP_ADDRESS_SPACE_SHIFT]) > > (i think we could make that more readable by adding > #define swp_as(entry) (swp_offset(entry) >> SWAP_ADDRESS_SPACE_SHIFT) > but i digress) Yes. This sounds good. > If, instead, we call page_file_mapping(page) and PageSwapCache is true, > we do this: > > return page_swap_info(page)->swap_file->f_mapping; > > struct swap_info_struct *page_swap_info(struct page *page) > { > swp_entry_t entry = { .val = page_private(page) }; > return swp_swap_info(entry); > } > > struct swap_info_struct *swp_swap_info(swp_entry_t entry) > { > return swap_type_to_swap_info(swp_type(entry)); > } > > static struct swap_info_struct *swap_type_to_swap_info(int type) > { > if (type >= READ_ONCE(nr_swapfiles)) > return NULL; > > smp_rmb(); /* Pairs with smp_wmb in alloc_swap_info. */ > return READ_ONCE(swap_info[type]); > } > > So ... are these different address spaces from each other? Yes. They are different. The address space from page_mapping(page) is used to hold pages in swap cache, they are not associated with some inodes in fact. While the address space from page_file_mapping(page) is used to read/write swap pages sometimes (please check __swap_writepage()). But page_file_mapping() isn't called there. Best Regards, Huang, Ying > If not, why do we have such a complicated way of finding the address > space for page_file_mapping()?