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=-4.1 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 8BCA9C433E0 for ; Mon, 10 Aug 2020 14:41:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 485442070B for ; Mon, 10 Aug 2020 14:41:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CnzTfUG1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 485442070B 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 AF3EA6B0005; Mon, 10 Aug 2020 10:41:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACAED6B0006; Mon, 10 Aug 2020 10:41:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BBAB6B0007; Mon, 10 Aug 2020 10:41:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id 8378B6B0005 for ; Mon, 10 Aug 2020 10:41:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0607340D7 for ; Mon, 10 Aug 2020 14:41:23 +0000 (UTC) X-FDA: 77134922046.30.mind13_1e0fc0026fdb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id B1BF0180B3C85 for ; Mon, 10 Aug 2020 14:41:22 +0000 (UTC) X-HE-Tag: mind13_1e0fc0026fdb X-Filterd-Recvd-Size: 6674 Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Aug 2020 14:41:22 +0000 (UTC) Received: by mail-il1-f194.google.com with SMTP id i15so7007386ils.9 for ; Mon, 10 Aug 2020 07:41:22 -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=AidFlRL4Ug1HXYYI29mKf2liuKC4nCVYEFXiYCfw8vA=; b=CnzTfUG1SpGkNdLlwHUtFMtEAs/lYxwUd5HQM1e687MC6Hx2DVg0XbIOvx3VGO/z74 /BRzNFMM9NnDz2jGQ2eASuxPpT/aB1AR3sUY0B97X9ZHGQols8ol6MIVMfMib/g48r13 +dOLOiywM+Fr6cEXRyNvtKTpvkt+vkdJGpS12tNiDQHg2E6/oVBCkQt5kLDzQO++FKwV Zwa8lmALUMlCqBfNzCEQDtTttA1A9PzbVF4AwYgmbywQm+6czKeFZ5vEr8+0JbKwwxts sbFCWoV2tT9H22iM4NLHNgkJvREVNYHhnlEWB8Dlv9Z67SOBGa1vmez+KhDjL99Dr6uA yZxA== 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=AidFlRL4Ug1HXYYI29mKf2liuKC4nCVYEFXiYCfw8vA=; b=pHEM3r/xhxYDTer4VkW7s5X0H2hiaiQV+QqGe6BqYpMqyDHMk9hckSNtO06l9JKfFE UeFy1U2LyQbiPBNF1yb4DB5THkDR2TFcjLQTZ7JR8kT9u5GmV4/3RSG9yDx5BM6HZYbO W+zuTLWFTiBMtW5qpmr9U2158mJEjsySC5DCtcG0K7t9g0+tr3ueZjxlkM201gpiEOAL ZrbjavcCEVNlXUCddbTqZau+Fb5UCDqZx2qL/6Z8oWiNhltzdlSLdN7g+9NvdkaHp+JT XIAOn8aQ8PORn38KfTchxWOBSEUZC5amsETs7nqS1+RSGXYAdilCtHgQrsvFNsCv8ZIu 9vRg== X-Gm-Message-State: AOAM531PEAF5GkNj3ZxdjZS/+VzbrcCKl9pk45N2x+ibqNm8xoLpMhS6 3pXPHqeB4/qQkswV0/GBiF01K+QF3Snhpjxsq58= X-Google-Smtp-Source: ABdhPJzo3pJ+3eWBSe8FMd4AtlSqVEx0Qp8bdmYA3soM8Urzw4pi6Kq6Bjl43tvikMG3Q/MAI+I2PSwzGbulSOR3JuA= X-Received: by 2002:a05:6e02:143:: with SMTP id j3mr16319712ilr.97.1597070481282; Mon, 10 Aug 2020 07:41:21 -0700 (PDT) MIME-Version: 1.0 References: <1595681998-19193-1-git-send-email-alex.shi@linux.alibaba.com> <1595681998-19193-15-git-send-email-alex.shi@linux.alibaba.com> <241ca157-104f-4f0d-7d5b-de394443788d@linux.alibaba.com> <8dbd004e-8eba-f1ec-a5eb-5dc551978936@linux.alibaba.com> In-Reply-To: <8dbd004e-8eba-f1ec-a5eb-5dc551978936@linux.alibaba.com> From: Alexander Duyck Date: Mon, 10 Aug 2020 07:41:10 -0700 Message-ID: Subject: Re: [PATCH v17 14/21] mm/compaction: do page isolation first in compaction To: Alex Shi Cc: Andrew Morton , Mel Gorman , Tejun Heo , Hugh Dickins , Konstantin Khlebnikov , Daniel Jordan , Yang Shi , Matthew Wilcox , Johannes Weiner , kbuild test robot , linux-mm , LKML , cgroups@vger.kernel.org, Shakeel Butt , Joonsoo Kim , Wei Yang , "Kirill A. Shutemov" , Rong Chen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B1BF0180B3C85 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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, Aug 10, 2020 at 6:10 AM Alex Shi wrote= : > > > > =E5=9C=A8 2020/8/7 =E4=B8=8B=E5=8D=8810:51, Alexander Duyck =E5=86=99=E9= =81=93: > > I wonder if this entire section shouldn't be restructured. This is the > > only spot I can see where we are resetting the LRU flag instead of > > pulling the page from the LRU list with the lock held. Looking over > > the code it seems like something like that should be possible. I am > > not sure the LRU lock is really protecting us in either the > > PageCompound check nor the skip bits. It seems like holding a > > reference on the page should prevent it from switching between > > compound or not, and the skip bits are per pageblock with the LRU bits > > being per node/memcg which I would think implies that we could have > > multiple LRU locks that could apply to a single skip bit. > > Hi Alexander, > > I don't find problem yet on compound or skip bit usage. Would you clarify= the > issue do you concerned? > > Thanks! The point I was getting at is that the LRU lock is being used to protect these and with your changes I don't think that makes sense anymore. The skip bits are per-pageblock bits. With your change the LRU lock is now per memcg first and then per node. As such I do not believe it really provides any sort of exclusive access to the skip bits. I still have to look into this more, but it seems like you need a lock per either section or zone that can be used to protect those bits and deal with this sooner rather than waiting until you have found an LRU page. The one part that is confusing though is that the definition of the skip bits seems to call out that they are a hint since they are not protected by a lock, but that is exactly what has been happening here. The point I was getting at with the PageCompound check is that instead of needing the LRU lock you should be able to look at PageCompound as soon as you call get_page_unless_zero() and preempt the need to set the LRU bit again. Instead of trying to rely on the LRU lock to guarantee that the page hasn't been merged you could just rely on the fact that you are holding a reference to it so it isn't going to switch between being compound or order 0 since it cannot be freed. It spoils the idea I originally had of combining the logic for get_page_unless_zero and TestClearPageLRU into a single function, but the advantage is you aren't clearing the LRU flag unless you are actually going to pull the page from the LRU list. My main worry is that this is the one spot where we appear to be clearing the LRU bit without ever actually pulling the page off of the LRU list, and I am thinking we would be better served by addressing the skip and PageCompound checks earlier rather than adding code to set the bit again if either of those cases are encountered. This way we don't pseudo-pin pages in the LRU if they are compound or supposed to be skipped. Thanks. - Alex