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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C8985C18E5B for ; Mon, 16 Mar 2020 23:47:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6499C20674 for ; Mon, 16 Mar 2020 23:47:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CognDl13" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6499C20674 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A42466B0003; Mon, 16 Mar 2020 19:47:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F2DE6B0005; Mon, 16 Mar 2020 19:47:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E0F46B0007; Mon, 16 Mar 2020 19:47:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id 775FA6B0003 for ; Mon, 16 Mar 2020 19:47:07 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 61A465DD5 for ; Mon, 16 Mar 2020 23:47:07 +0000 (UTC) X-FDA: 76602863694.05.bike50_3e279368bcf0c X-HE-Tag: bike50_3e279368bcf0c X-Filterd-Recvd-Size: 5436 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Mar 2020 23:47:06 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id 39so4393616otu.3 for ; Mon, 16 Mar 2020 16:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aVXf02gC+H4hnLytwgf022jEbvbc1T3drxGD+ZV/fXY=; b=CognDl138DrQV5mRCWSZeKD5h8R45GijjA7lHIVKHSd3M2gwoWTuh1CcWFxzJggwT9 +mbFzZina4y6S4NrXLQtdNputZ25VHTvUZvB7PuH8rhkzW+olXLws4Z5JEsrXpgZfghh Q5ewT2IWI6/Qc4K8qvjubZSvWQN7lfmzEv3dch7MOqipMe7tm/IgsUgUSKKPoW1pTniu CaxxmKPSIIxvIj3Q/XUIfSEDQhibdE0swIgP8XyaUOWD4Exih2jFC98zL4qtxgiqWHxZ ufbESvKXQ695ue4yzniVnGXSGcrOVedTcuuISqN6pfzXeBMLpy3wjLO4n5wgoeUzdTWF la3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aVXf02gC+H4hnLytwgf022jEbvbc1T3drxGD+ZV/fXY=; b=S+XKv2VPzdufkXl6BGMca0O9U6dHvbQitHNIWBh3up4xNyI1RdjBbM1FIWBqPP9ewk hMMdWF75WkNlQwp+2aUnx41uO/HJmy5C+JV2/0lDxsq1veMNNzsrSfVlgU3Dg/+5YNzO 4aWLMgkMh+yoMekur8//2FkyiAWDWPxXV9EJhiZ3Gctj4pzGfFmxWG2LnpavEbvDfwVd kP+nu/fauY5QHf1DfI4NItvcumMEMVm+tLdwbtI1+bdtND1f/VI4eOevUhP63BmDEKf9 82Xhjq7BFPa/GrA/KyxhX32JdAzLLxgqwzwfvggz6zy1v6y2SrTYcrMJOa5CIY2FpAK6 CPyA== X-Gm-Message-State: ANhLgQ0gt38Z8sdDEjusFv1rB8/LUFKhnnnLymmLZODBD5CdWJCPw37O 4q6den3VwqWhnHa/R9vh9sUcS00Lh6b/iIHegb4yqw== X-Google-Smtp-Source: ADFU+vtLX9oIptyOrpGbEjvdyuNKgTeAthRn4FGLayQM9052N1kUTixf37hS0KhTcqxCa/Be6gmO09gRriEIpnqMuwI= X-Received: by 2002:a9d:6c99:: with SMTP id c25mr1407317otr.124.1584402425776; Mon, 16 Mar 2020 16:47:05 -0700 (PDT) MIME-Version: 1.0 References: <1584397455-28701-1-git-send-email-yang.shi@linux.alibaba.com> In-Reply-To: <1584397455-28701-1-git-send-email-yang.shi@linux.alibaba.com> From: Shakeel Butt Date: Mon, 16 Mar 2020 16:46:54 -0700 Message-ID: Subject: Re: [v2 PATCH 1/2] mm: swap: make page_evictable() inline To: Yang Shi Cc: Vlastimil Babka , Matthew Wilcox , Andrew Morton , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" 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: On Mon, Mar 16, 2020 at 3:24 PM Yang Shi wrote: > > When backporting commit 9c4e6b1a7027 ("mm, mlock, vmscan: no more > skipping pagevecs") to our 4.9 kernel, our test bench noticed around 10% > down with a couple of vm-scalability's test cases (lru-file-readonce, > lru-file-readtwice and lru-file-mmap-read). I didn't see that much down > on my VM (32c-64g-2nodes). It might be caused by the test configuration, > which is 32c-256g with NUMA disabled and the tests were run in root memcg, > so the tests actually stress only one inactive and active lru. It > sounds not very usual in mordern production environment. > > That commit did two major changes: > 1. Call page_evictable() > 2. Use smp_mb to force the PG_lru set visible > > It looks they contribute the most overhead. The page_evictable() is a > function which does function prologue and epilogue, and that was used by > page reclaim path only. However, lru add is a very hot path, so it > sounds better to make it inline. However, it calls page_mapping() which > is not inlined either, but the disassemble shows it doesn't do push and > pop operations and it sounds not very straightforward to inline it. > > Other than this, it sounds smp_mb() is not necessary for x86 since > SetPageLRU is atomic which enforces memory barrier already, replace it > with smp_mb__after_atomic() in the following patch. > > With the two fixes applied, the tests can get back around 5% on that > test bench and get back normal on my VM. Since the test bench > configuration is not that usual and I also saw around 6% up on the > latest upstream, so it sounds good enough IMHO. > > The below is test data (lru-file-readtwice throughput) against the v5.6-rc4: > mainline w/ inline fix > 150MB 154MB > > With this patch the throughput gets 2.67% up. The data with using > smp_mb__after_atomic() is showed in the following patch. > > Fixes: 9c4e6b1a7027 ("mm, mlock, vmscan: no more skipping pagevecs") > Cc: Shakeel Butt > Cc: Vlastimil Babka > Cc: Matthew Wilcox > Signed-off-by: Yang Shi So, I tested on a real machine with limiting the 'dd' on a single node and reading 100 GiB sparse file (less than a single node). I just ran a single instance to not cause the lru lock contention. The cmd I used is "dd if=file-100GiB of=/dev/null bs=4k". I ran the cmd 10 times with drop_caches in between and measured the time it took. Without patch: 56.64143 +- 0.672 sec With patches: 56.10 +- 0.21 sec Reviewed-and-Tested-by: Shakeel Butt