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;
Date:   Mon, 16 Aug 2021 01:43:24 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     David Howells <dhowells@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v14 081/138] mm: Add folio_evictable()
Message-ID: <YRm0rCTY7G1xVbFl@casper.infradead.org>
References: <20210715033704.692967-82-willy@infradead.org>
 <20210715033704.692967-1-willy@infradead.org>
 <1814102.1628631690@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1814102.1628631690@warthog.procyon.org.uk>
Precedence: bulk

On Tue, Aug 10, 2021 at 10:41:30PM +0100, David Howells wrote:
> Matthew Wilcox (Oracle) <willy@infradead.org> wrote:
> 
> > This is the folio equivalent of page_evictable().  Unfortunately, it's
> > different from !folio_test_unevictable(), but I think it's used in places
> > where you have to be a VM expert and can reasonably be expected to know
> > the difference.
> 
> It would be useful to say how it is different.  I'm guessing it's because a
> page is always entirely mlocked or not, but a folio might be partially
> mlocked?

folio_test_unevictable() checks the unevictable page flag.
folio_evictable() tests whether the folio is evictable (is any page
in the folio part of an mlocked VMA, or has the filesystem marked
the inode as being unevictable (eg is it ramfs).

It does end up looking a bit weird though.

                if (page_evictable(page) && PageUnevictable(page)) {
                        del_page_from_lru_list(page, lruvec);
                        ClearPageUnevictable(page);
                        add_page_to_lru_list(page, lruvec);

but it's all mm-internal, not exposed to filesystems.