Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2544676pxa; Mon, 17 Aug 2020 12:19:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6G4veYRUtNafYBNIe7325NBj2gxZbbl+9B9n+Kr0kQLbPXTsekoD9m0Dp7IHqMpDOvTri X-Received: by 2002:a17:907:7292:: with SMTP id dt18mr17358285ejc.512.1597691994970; Mon, 17 Aug 2020 12:19:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597691994; cv=none; d=google.com; s=arc-20160816; b=zRQNtEHcsInnxfhk85g/41CfRHvBC32MUZsxzfrIV8WaqVdvQp8kjbEneIhwb508sx 6aobOCICU00njkpZUp2m1OA9DsLJnBZNDH4BvkX21Rc0fDEy5ZKqRSG/wQlOGYLDG91+ p0PhSLoPmL3ml2dHtElwURFdwUpq+PYptsqJQ6QiE+cg19sj8qn0C8xhN2qoC6S/4TOS YoZ2QBOnIsYPhdwJkVMvawWiKr1Nzk19og6DQBC8ZnRveZ8lG8y1N6LaMvqQMpch8T8+ azEnw/81aRT4KrGM/O3D4qTKqa0z8X2qIL/se8f2EP+UVCFqA2eqfGEHlLjjRfRPLn6B rDXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4Bkdz+k72rLGRx5zfmph4t7mOQMS3PzCCK/DsnCmnNk=; b=k5z5cmkpioPk3XWBu3N5t03HzowWbPI4umr6K7e9qRA/6dEdIYFPrtNNazCxevgeCD uBWEuLjywpifVBJBZTaMYJ+DXLL2T8wVSHd+wMdtB+PREVUW4eKlLbxRRNoepeQyxpOH bB5mC/qVoisszC961/ogA38SU8y+HfmHXPenenZQ5fAcaM+AUlMAeL6DoXr+pTLGNGoQ LFYJs7o8q5Q+Zryqz+hzHQvHQvemvlCjFy0ByB6En6DIq180OPKUyQTJr7yCeki3hDjw IIEVnlAbmMkPt8dER+FrTpJ6NSv49Q2cW9r3mAaUHVBGz+yXz/DBG5Nf9O7MD86zdDFR lFWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IUxAnms4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p12si11429390edy.553.2020.08.17.12.19.31; Mon, 17 Aug 2020 12:19:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IUxAnms4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392248AbgHQTR6 (ORCPT + 99 others); Mon, 17 Aug 2020 15:17:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730582AbgHQPiO (ORCPT ); Mon, 17 Aug 2020 11:38:14 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E301C061389; Mon, 17 Aug 2020 08:38:14 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id v6so17948263iow.11; Mon, 17 Aug 2020 08:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4Bkdz+k72rLGRx5zfmph4t7mOQMS3PzCCK/DsnCmnNk=; b=IUxAnms4s7sSclWkvmw5QiiHjkg484hwDAcSl/TapXh0pQyfDNpoGhtsiLGdSP8sI/ rJ3nFoUmNjxtIlAuvyzlLaT+dNCimN4koRcvtUfx34lpUMOAitgRZOoSGPR/faSU36+h W5P3Fnp/zOYblyl4nLFp35Nn3FWPjieLKlt0s279lug2G5pIov2EQZ456vEhAt+0gU2P UUNVf7+sJ7+D3VGcI1+FDJ0mRse6hzZ2N4+R64jBzVA5DRfFjeGhMTN8BHPrUAEyGdWU WAP7k37sKE7kIjzWuy+Wk4na9F1Am+y7QYk/VIDlyxwUKIKPvwVKQYDv+2+YYuiR+89Y rVTw== 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:content-transfer-encoding; bh=4Bkdz+k72rLGRx5zfmph4t7mOQMS3PzCCK/DsnCmnNk=; b=js90b07Gq0i+sHjsd8SIDwEsiqeV+IubNf9QCIJH78S7McP25hP4vdWhyDQlUeLvCM xSNmcdAFXjx3mgXlgtu1bInk/GsqBGdL87JmW4LC9Sh+E2/MCxpvsID675c40KX4AQl/ Ac0z8RzGhV/Jx7z98dUordJ5osuazCfJRIzHm82hxMXdXl2Uvn1h1K0SlOTK1ep2f2NN oRfmIywaYtcYjpIMBn58SvHkkVlt82IlKU2XCbrYVr3eQd+43J6+NyJNUwdCD64V0Skk 5cNxT34743VnAPZqh5Ewy1RO1D+eDFy0m0tR/DKHd/Qpm/6tEuAgjn3s7A/yYzKpGzkN +f4g== X-Gm-Message-State: AOAM530K7vtnkP05ne87QQp8JIQecwu+NrINBNAEoDxdIbMQj3CwJWok b1cnpSdEMvCf0+ks1XgNP4M7f7po6Slkdi7LesM= X-Received: by 2002:a5d:9051:: with SMTP id v17mr12402353ioq.88.1597678693579; Mon, 17 Aug 2020 08:38:13 -0700 (PDT) MIME-Version: 1.0 References: <20200813035100.13054.25671.stgit@localhost.localdomain> <20200813040232.13054.82417.stgit@localhost.localdomain> <6c072332-ff16-757d-99dd-b8fbae131a0c@linux.alibaba.com> <650ab639-e66f-5ca6-a9a5-31e61c134ae7@linux.alibaba.com> In-Reply-To: <650ab639-e66f-5ca6-a9a5-31e61c134ae7@linux.alibaba.com> From: Alexander Duyck Date: Mon, 17 Aug 2020 08:38:02 -0700 Message-ID: Subject: Re: [RFC PATCH 2/3] mm: Drop use of test_and_set_skip in favor of just setting skip To: Alex Shi Cc: Yang Shi , kbuild test robot , Rong Chen , Konstantin Khlebnikov , "Kirill A. Shutemov" , Hugh Dickins , LKML , Daniel Jordan , linux-mm , Shakeel Butt , Matthew Wilcox , Johannes Weiner , Tejun Heo , cgroups@vger.kernel.org, Andrew Morton , Wei Yang , Mel Gorman , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 15, 2020 at 2:51 AM Alex Shi wrote= : > > > > =E5=9C=A8 2020/8/15 =E4=B8=8A=E5=8D=885:15, Alexander Duyck =E5=86=99=E9= =81=93: > > On Fri, Aug 14, 2020 at 7:24 AM Alexander Duyck > > wrote: > >> > >> On Fri, Aug 14, 2020 at 12:19 AM Alex Shi = wrote: > >>> > >>> > >>> > >>> =E5=9C=A8 2020/8/13 =E4=B8=8B=E5=8D=8812:02, Alexander Duyck =E5=86= =99=E9=81=93: > >>>> > >>>> Since we have dropped the late abort case we can drop the code that = was > >>>> clearing the LRU flag and calling page_put since the abort case will= now > >>>> not be holding a reference to a page. > >>>> > >>>> Signed-off-by: Alexander Duyck > >>> > >>> seems the case-lru-file-mmap-read case drop about 3% on this patch in= a rough testing. > >>> on my 80 core machine. > >> > >> I'm not sure how it could have that much impact on the performance > >> since the total effect would just be dropping what should be a > >> redundant test since we tested the skip bit before we took the LRU > >> bit, so we shouldn't need to test it again after. > >> > >> I finally got my test setup working last night. I'll have to do some > >> testing in my environment and I can start trying to see what is going > >> on. > > > > So I ran the case-lru-file-mmap-read a few times and I don't see how > > it is supposed to be testing the compaction code. It doesn't seem like > > compaction is running at least on my system as a result of the test > > script. > > atteched my kernel config, it is used on mine machine, I'm just wondering what the margin of error is on the tests you are running. What is the variance between runs? I'm just wondering if 3% falls into the range of noise or possible changes due to just code shifting around? In order for the code to have shown any change it needs to be run and I didn't see the tests triggering compaction on my test system. I'm wondering how much memory you have available in the system you were testing on that the test was enough to trigger compaction? > > I wonder if testing this code wouldn't be better done using > > something like thpscale from the > > mmtests(https://github.com/gormanm/mmtests)? It seems past changes to > > the compaction code were tested using that, and the config script for > > the test explains that it is designed specifically to stress the > > compaction code. I have the test up and running now and hope to > > collect results over the weekend. > > I did the testing, but a awkward is that I failed to get result, > maybe leak some packages. So one thing I noticed is that if you have over 128GB of memory in the system it will fail unless you update the sysctl value vm.max_map_count. It defaulted to somewhere close to 64K, and I increased it 20X to 1280K in order for the test to run without failing on the mmap calls. The other edit I had to make was the config file as the test system I was on had about 1TB of RAM, and my home partition only had about 800GB to spare so I had to reduce the map size from 8/10 to 5/8. > # ../../compare-kernels.sh > > thpscale Fault Latencies > Can't locate List/BinarySearch.pm in @INC (@INC contains: /root/mmtests/b= in/lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendo= r_perl /usr/share/perl5/vend. > BEGIN failed--compilation aborted at /root/mmtests/bin/lib/MMTests/Stat.p= m line 13. > Compilation failed in require at /root/mmtests/work/log/../../bin/compare= -mmtests.pl line 13. > BEGIN failed--compilation aborted at /root/mmtests/work/log/../../bin/com= pare-mmtests.pl line 13. I had to install List::BinarySearch.pm. It required installing the cpan perl libraries. > > > > There is one change I will probably make to this patch and that is to > > place the new code that is setting skip_updated where the old code was > > calling test_and_set_skip_bit. By doing that we can avoid extra checks > > and it should help to reduce possible collisions when setting the skip > > bit in the pageblock flags. > > the problem maybe on cmpchxg pb flags, that may involved other blocks cha= nges. That is the only thing I can think of just based on code review. Although that would imply multiple compact threads are running, and as I said in my tests I never saw kcompactd wakeup so I don't think the tests you were mentioning were enough to stress compaction.