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.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 4EB13C433E1 for ; Thu, 20 Aug 2020 14:13:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 104A220724 for ; Thu, 20 Aug 2020 14:13:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TCJZNgYl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 104A220724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9E1878D0029; Thu, 20 Aug 2020 10:13:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 991E48D0002; Thu, 20 Aug 2020 10:13:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A8758D0029; Thu, 20 Aug 2020 10:13:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 7241F8D0002 for ; Thu, 20 Aug 2020 10:13:51 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 21051180AD801 for ; Thu, 20 Aug 2020 14:13:51 +0000 (UTC) X-FDA: 77171140662.23.error49_050d0f527031 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 926AE37606 for ; Thu, 20 Aug 2020 14:13:43 +0000 (UTC) X-HE-Tag: error49_050d0f527031 X-Filterd-Recvd-Size: 5201 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 14:13:41 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id v6so2281101iow.11 for ; Thu, 20 Aug 2020 07:13:41 -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=7KUqD0NVyRg3Zo03GZrFVQegwrcexF2aJREuag4UjIs=; b=TCJZNgYlFkolAtKYDIaSQN1FZqYOp0XkIPkHM5WH42LWR6/yUHnPUjst8eHDeJmbVI j5LsQXv6294iLVbd3J87FiCydVMOuBJ0fa9oex0OUM92w/tFyJmNbRU8b1a1MM1c5uyN 785YJ3lAM9LVM2OjK3bnrI51rakDkVrQRnhg68McF4HsFIfOb7naUtnS8WgGlVCen2uL DQ6HuaO1AY/+oE+9Y09w9SJnDdZjAfNT0twocg+yXtnzrQxMVmNyS9CdKBKqTpezXNHM gAvy5RnVll4PadjCJ/Vi3pdvgimSd0fUCj+odJhmONiUJCgifJsi+1UkihKXhBJ/4T/1 IKaA== 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=7KUqD0NVyRg3Zo03GZrFVQegwrcexF2aJREuag4UjIs=; b=czDw4S9tFrmNnFXbXT+xTQac3IKkqvDjwYxPC2S3YtDQX5FgXBo357FL+sryBbeWg6 zvVqg+x0KpFR0sJuP2Ypz6F+aNbijNakpkBm7IEfFkFqPtgPVuiNYAhHUPvojejOMWGG Fr5XxmL3VEt24fSpm1obM57jUos8C5gSWpzQJziTNy+pZiz8kaghXYvM5ZhXHTs4TdLV J3QdzjU/Kz2TyqpFsO+JfcDcNvyb24fpgCL0Wz+9JrWEZ05NMmPGBNXaMfM00DcKb/zK MaQoiFUvJ0kWql+iKojoL/0J5C2aMj50h/joK/MihVgZ7dvnfy3eqDqQ0rW3QQZYrqkZ HusQ== X-Gm-Message-State: AOAM533hBapXWfsIZB1hyPoCEr7lupZqqO4i/E1WlrWnrDjHEVhCcKuL lSzLRpHlKAbG21y9tMdQQ32NkQTiXqIXu5FwM6A= X-Google-Smtp-Source: ABdhPJwbWC38Bz5MDaAGOI9NDW7tN+sr5sluyUNIxyH9tFJgxZZ0l6sSTtfBdLeGoYx1fATjeKxgHnjjjN1eF7MNVBw= X-Received: by 2002:a05:6638:1508:: with SMTP id b8mr3408874jat.96.1597932821221; Thu, 20 Aug 2020 07:13:41 -0700 (PDT) MIME-Version: 1.0 References: <20200819041852.23414.95939.stgit@localhost.localdomain> <20200819042730.23414.41309.stgit@localhost.localdomain> <15edf807-ce03-83f7-407d-5929341b2b4e@linux.alibaba.com> In-Reply-To: From: Alexander Duyck Date: Thu, 20 Aug 2020 07:13:30 -0700 Message-ID: Subject: Re: [RFC PATCH v2 4/5] mm: Split release_pages work into 3 passes 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 X-Rspamd-Queue-Id: 926AE37606 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Thu, Aug 20, 2020 at 2:51 AM Alex Shi wrote= : > > > > =E5=9C=A8 2020/8/19 =E4=B8=8B=E5=8D=8810:57, Alexander Duyck =E5=86=99=E9= =81=93: > >>> lruvec =3D relock_page_lruvec_irqsave(page, lruvec, &flags); > >> the lock bounce is better with the patch, would you like to do further > >> like using add_lruvecs to reduce bounce more? > >> > >> Thanks > >> Alex > > I'm not sure how much doing something like that would add. In my case > > I had a very specific issue that this is addressing which is the fact > > that every compound page was taking the LRU lock and zone lock > > separately. With this patch that is reduced to one LRU lock per 15 > > pages and then the zone lock per page. By adding or sorting pages by > > lruvec I am not sure there will be much benefit as I am not certain > > how often we will end up with pages being interleaved between multiple > > lruvecs. In addition as I am limiting the quantity to a pagevec which > > limits the pages to 15 I am not sure there will be much benefit to be > > seen for sorting the pages beforehand. > > > > the relock will unlock and get another lock again, the cost in that, the = 2nd > lock need to wait for fairness for concurrency lruvec locking. > If we can do sort before, we should remove the fairness waiting here. Of = course, > perf result depends on scenarios. Agreed. The question is in how many scenarios are you going to have pages interleaved between more than one lruvec? I suspect in most cases you should only have one lruvec for all the pages being processed in a single pagevec.