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 64908C433E0 for ; Fri, 7 Aug 2020 14:51:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D1332075D for ; Fri, 7 Aug 2020 14:51:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DZl9SjSA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D1332075D 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 92F4B8D0001; Fri, 7 Aug 2020 10:51:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DDB06B0033; Fri, 7 Aug 2020 10:51:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CDE08D0001; Fri, 7 Aug 2020 10:51:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 66DCF6B0032 for ; Fri, 7 Aug 2020 10:51:24 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E716D180AD804 for ; Fri, 7 Aug 2020 14:51:23 +0000 (UTC) X-FDA: 77124060846.05.wire88_351821826fc1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id BB1091802E8C5 for ; Fri, 7 Aug 2020 14:51:23 +0000 (UTC) X-HE-Tag: wire88_351821826fc1 X-Filterd-Recvd-Size: 5321 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 7 Aug 2020 14:51:23 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id g19so2148930ioh.8 for ; Fri, 07 Aug 2020 07:51:23 -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=j7YOCwyn015CH01DvuqygeICt/lkosNS0VPJxx8lTNk=; b=DZl9SjSAU9r2ocCJ25zl96LApqZMSw7v9QRevy/vcPN769EjunTsd/mxoDROifcfLh x1cV0CIGT6g0Xi8y8o6WulDNVEU3MgOjy374LzN50bwKA8qj5tfqhfRG9Q0nekJQju22 GCXzILsDGgSQKEM3LcX5k/g1Xw3f41snt8i8oCINtSQ6N5YA/eiSfFTAreko0JF3PNtH J9p4yKgszZfUSwY6ChDo83EAwG/Mcts7/mmesRa55fDcCkl3YPCe0tulykRKtrpaxq9l jtyCfQeWNNNxCOjCAqiccXa6SPaZBiUkyk+VyHgZacF4AyPUX6DZFp/FbQH052q+PY5Y i1DA== 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=j7YOCwyn015CH01DvuqygeICt/lkosNS0VPJxx8lTNk=; b=KNlXteNI23c0Gi4oFFO3mcf2X7RXw2EIy7HURsFBj1nHcchstqI2H7cy5lfxyMhCT2 RKJmLW7iESXskPPY0yNC9wXF+aqnfm2XlNgvx+Ka5a5XNAjYLR6jZzNI/2nQsZCvRvkG inH45p6g1jYeF68TKeOCfTaRgjd1q1SgjSI7wIrLAh8pgLOsM8LC1Ooqk2A6G5r+KmMA N50aXG6zjuRQmQnJGyH5ukL2GejpLcZpYT3Soru9zEOo1j7L5Bh0rtYO6gxEEPZLcsqr YgI94tVQLtzW9atjRye+ecEk4p2MNiYN0YjTKPhYXCOC74XplS4zicWKnVRXMX7JyxDR N1Zw== X-Gm-Message-State: AOAM532GJTgs8N2ZWIS4saXxhIpi9Ydabm7LQAN91QYFXoNE84XT0CI0 7yPDJyQWl1XDvMty/GLUQRNj0JLX7LojpvKgMes= X-Google-Smtp-Source: ABdhPJxeOx00W3je8vxOviLsrpuWMtz8cLUXTLbWzgM8MrwxscvD0ivTRszWuF80qgyakY297NlCJywTb4dj8OBja+A= X-Received: by 2002:a05:6602:2e83:: with SMTP id m3mr4976673iow.38.1596811882640; Fri, 07 Aug 2020 07:51:22 -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> In-Reply-To: <241ca157-104f-4f0d-7d5b-de394443788d@linux.alibaba.com> From: Alexander Duyck Date: Fri, 7 Aug 2020 07:51:11 -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: BB1091802E8C5 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 Thu, Aug 6, 2020 at 8:25 PM Alex Shi wrote: > > > > =E5=9C=A8 2020/8/7 =E4=B8=8A=E5=8D=882:38, Alexander Duyck =E5=86=99=E9= =81=93: > >> + > >> isolate_abort: > >> if (locked) > >> spin_unlock_irqrestore(&pgdat->lru_lock, flags); > >> + if (page) { > >> + SetPageLRU(page); > >> + put_page(page); > >> + } > >> > >> /* > >> * Updated the cached scanner pfn once the pageblock has been = scanned > > We should probably be calling SetPageLRU before we release the lru > > lock instead of before. It might make sense to just call it before we > > get here, similar to how you did in the isolate_fail_put case a few > > lines later. Otherwise this seems to violate the rules you had set up > > earlier where we were only going to be setting the LRU bit while > > holding the LRU lock. > > Hi Alex, > > Set out of lock here should be fine. I never said we must set the bit in = locking. > And this page is get by get_page_unless_zero(), no warry on release. > > Thanks > Alex 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.