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 7BAD8C4361B for ; Thu, 17 Dec 2020 01:57:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 02CEC23436 for ; Thu, 17 Dec 2020 01:57:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 02CEC23436 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 2DA436B0036; Wed, 16 Dec 2020 20:57:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2634E6B005D; Wed, 16 Dec 2020 20:57:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1520B6B0068; Wed, 16 Dec 2020 20:57:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id EDE216B0036 for ; Wed, 16 Dec 2020 20:57:34 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B50E7180AD81D for ; Thu, 17 Dec 2020 01:57:34 +0000 (UTC) X-FDA: 77601112428.30.mark69_3d06dd927431 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 9300D180B3C85 for ; Thu, 17 Dec 2020 01:57:34 +0000 (UTC) X-HE-Tag: mark69_3d06dd927431 X-Filterd-Recvd-Size: 2467 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Dec 2020 01:57:33 +0000 (UTC) IronPort-SDR: CYg7ab63puEiWMc1AqHc5LuZnvUKwz37+XDl37yr0AwEvmogsjdaMHpmAxSJZW4n8Mipcs/hrH 8bpOQRzB4yoA== X-IronPort-AV: E=McAfee;i="6000,8403,9837"; a="162917400" X-IronPort-AV: E=Sophos;i="5.78,425,1599548400"; d="scan'208";a="162917400" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2020 17:57:31 -0800 IronPort-SDR: G9mH2seQiskxJD+AzJNeef9FhQa9vGVsUyOVovCymdjeYt4miJclnydcZUIxoknteu7vIoTMUc mfL9NMvlNd3w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,425,1599548400"; d="scan'208";a="369480279" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.50]) by orsmga008.jf.intel.com with ESMTP; 16 Dec 2020 17:57:28 -0800 From: "Huang\, Ying" To: Minchan Kim Cc: Joonsoo Kim , Johannes Weiner , Vlastimil Babka , Hugh Dickins , Mel Gorman , Michal Hocko , Dan Williams , Christoph Hellwig , Ilya Dryomov , Andrew Morton , linux-mm Subject: Do we still need skip swapcache logic in do_swap_page() for SWP_SYNCHRONOUS_IO? Date: Thu, 17 Dec 2020 09:57:28 +0800 Message-ID: <87y2hxgpo7.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Hi, Minchan, In commit 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device"), swap cache management is skipped for super fast device with synchronous IO. That did help performance for these devices much at that time. But in commit aae466b0052e ("mm/swap: implement workingset detection for anonymous LRU"), swap cache is used to record workingset shadow value. So it needs to be operated anyway in swapin in common cases. Although lockless operation get_shadow_from_swap_cache() is used now, in swap_free() path, swap cache will be locked. So now, is it still necessary to skip swap cache logic in do_swap_page() for SWP_SYNCHRONOUS_IO? Maybe we can just simplify the logic? Best Regards, Huang, Ying