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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 D4500CA9EC5 for ; Wed, 30 Oct 2019 19:33:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68B362080F for ; Wed, 30 Oct 2019 19:33:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="oChDfMz/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68B362080F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B8D6C6B0008; Wed, 30 Oct 2019 15:33:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B37976B000A; Wed, 30 Oct 2019 15:33:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A26A56B000C; Wed, 30 Oct 2019 15:33:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 8128E6B0008 for ; Wed, 30 Oct 2019 15:33:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 1E6546D7E for ; Wed, 30 Oct 2019 19:33:13 +0000 (UTC) X-FDA: 76101449466.03.space09_9066d96c1fd45 X-HE-Tag: space09_9066d96c1fd45 X-Filterd-Recvd-Size: 5986 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 19:33:12 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id e4so2161445pgs.1 for ; Wed, 30 Oct 2019 12:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=aSReImkSLsqHemQmGOxqvj6ay7FURrqUrWNYRRQXyzw=; b=oChDfMz//zG2Pf1uKD8sRMNO2pze5RCorhzVb78EvTeJRFLk+P0r5uB9pPpQjni8F1 LHeVKHnr1LucIzspLAlfdbvQ0TVSMWmG7xnro12hG8VLBdMvkaPMYlvTqntrk+sWPEET bBm1L44SitGpfdhCHRwoHp7JOVkPkevQmQNCI6cPM7jnaU6vQM2q6KbNbUoki7uEVJ7j 4KGp+MupREOY107l6zUC0XmQs+GiD+jnBAlxs3o+QQVQA8tKsMdY3uQkt0oE5XsCQU6J sEUD5R5LYiUmHA/UucHyj+WDvuv2tmirKfW4FvjwM5mo2V0g7+ETUFCboAk4YWK5tNYw lAlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=aSReImkSLsqHemQmGOxqvj6ay7FURrqUrWNYRRQXyzw=; b=km2lP/FklYAZRl0ngZvA23blrh5q+eGhRaPEaNMDIvL5MD9BaciHD1Fwi1MTonVqd9 K9I8LK4yqYOV8S7sphTtvDejVYr1GcRkfZWyAqCqyBkbuU8hqQfMrkaYae8k3N2wihhI 118eJag4GtHT7kvVAfPZ6RCVhMWnd4T9kFvjSu2TovbuNK4Lnk0Xlb8n5KWAohTUsL2h 7hcC5t0ZzP3uiNgU4m9bX+iWA5WnL8pmOAX9zhMpUTNLmjQuEF2L3jGTH8dxx7Hrjs2l E0ncGUwGIoAyRo3NB1qTbWuTnMKlPwrdftrC2vPNapWu2q2yLKKe6m4tdcTzdZrbycG+ JNiw== X-Gm-Message-State: APjAAAVhVVir4nDmyNedcMrijrC7n42PykQgc2xpIZ6aU9bhx0JPEn9A qvCEv/goRRUNSVEyZlGje0rflg== X-Google-Smtp-Source: APXvYqz+LU8shnIBKSdpYM8GsMXbRwYx/p5m7OIjIFqhxcsGHkYajSsBXJIfkgd1IMPBZmtxaJqSwA== X-Received: by 2002:a17:90a:9310:: with SMTP id p16mr1174316pjo.24.1572463990845; Wed, 30 Oct 2019 12:33:10 -0700 (PDT) Received: from localhost ([2620:10d:c090:180::78bd]) by smtp.gmail.com with ESMTPSA id q200sm739955pfq.87.2019.10.30.12.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 12:33:09 -0700 (PDT) Date: Wed, 30 Oct 2019 15:33:07 -0400 From: Johannes Weiner To: Michal Hocko Cc: Minchan Kim , zhong jiang , akpm@linux-foundation.org, ktkhai@virtuozzo.com, linux-mm@kvack.org Subject: Re: [PATCH] mm: fix unevictable page reclaim when calling madvise_pageout Message-ID: <20191030193307.GA48128@cmpxchg.org> References: <1572275317-63910-1-git-send-email-zhongjiang@huawei.com> <20191029081102.GB31513@dhcp22.suse.cz> <5DB806D1.8020503@huawei.com> <20191029094039.GH31513@dhcp22.suse.cz> <5DB81838.6020208@huawei.com> <20191030165239.GA167773@google.com> <20191030174533.GL31513@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030174533.GL31513@dhcp22.suse.cz> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Wed, Oct 30, 2019 at 06:45:33PM +0100, Michal Hocko wrote: > On Wed 30-10-19 09:52:39, Minchan Kim wrote: > > On Tue, Oct 29, 2019 at 06:45:12PM +0800, zhong jiang wrote: > > > On 2019/10/29 17:40, Michal Hocko wrote: > > > > On Tue 29-10-19 17:30:57, zhong jiang wrote: > > > >> On 2019/10/29 16:11, Michal Hocko wrote: > > > >>> [Cc Minchan] > > > > [...] > > > >>> Removing a long existing BUG_ON begs for a much better explanation. > > > >>> shrink_page_list is not a trivial piece of code but I _suspect_ that > > > >>> removing it should be ok for mapped pages at least (try_to_unmap) but I > > > >>> am not so sure how unmapped unevictable pages are handled from top of my > > > >>> head. > > > >> As to the unmapped unevictable pages. shrink_page_list has taken that into account. > > > >> > > > >> shinkr_page_list > > > >> page_evictable --> will filter the unevictable pages to putback its lru. > > > > Ohh, it is right there at the top. Missed it. The check has been added > > > > by Nick along with the BUG_ON. So it is sounds more like a "this > > > > shouldn't happen" bugon. I wouldn't mind to remove it with that > > > > justification. > > > As you has said, Minchan fix the same kind of bug by checking PageUnevictable (I did not notice before) > > > Wait for Minchan to see whether he has better reason. thanks, > > > > madvise_pageout could work with a shared page and one of the vmas among processes > > could do mlock so it could pass Unevictable LRU pages into shrink_page_list. > > It's pointless to try reclaim unevictable pages from the beginning so I want to fix > > madvise_pageout via introducing only_evictable flag into the API so that > > madvise_pageout uses it as "true". > > > > If we want to remove the PageUnevictable VM_BUG_ON_PAGE in shrink_page_list, > > I want to see more strong reason why it happens and why caller couldn't > > filter them out from the beginning. > > Why is this preferable over removing the VM_BUG_ON condition? In other > words why should we keep PageUnevictable check there? The mlock LRU shuffling is a bit tricky and can race with page reclaim or others isolating the page from the LRU list. If another isolator wins, it has to move the page during putback on behalf of mlock. See the implementation and comments in __pagevec_lru_add_fn(). That's why page reclaim can see !page_evictable(), but it must not see pages that have the PageUnevictable lru bit already set. Because that would mean the isolation/putback machinery messed up somewhere and the page LRU state is corrupt. As that machinery is non-trivial, it's useful to have that sanity check in page reclaim.