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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EB64C433F5 for ; Mon, 18 Oct 2021 17:25:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B0E4961077 for ; Mon, 18 Oct 2021 17:25:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B0E4961077 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4D77D900004; Mon, 18 Oct 2021 13:25:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4391E900002; Mon, 18 Oct 2021 13:25:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28C9B900004; Mon, 18 Oct 2021 13:25:04 -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 16DBA900002 for ; Mon, 18 Oct 2021 13:25:04 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C0341181C223F for ; Mon, 18 Oct 2021 17:25:03 +0000 (UTC) X-FDA: 78710233686.32.10EAE4B Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 30C5EF000136 for ; Mon, 18 Oct 2021 17:25:03 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id z24so15907391qtv.9 for ; Mon, 18 Oct 2021 10:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VlN35XgI9PTndq7UxTnTEbK2ldcab2451jgEL0ZSqaM=; b=qK2G14Y736gLbmF8WeKdXEgMl+G2OGQsU1fCBVh2NbNOEaezcH6NAqAKw0aIYyZZCY D0KjQ9Om6zpzcSkUOCw7nfDWo0peXjwGkI0PVkNdxmJdgcW5VWEhKddNxgrVqT2nmUfy plc7yiDP5oXfPS1xwECNcCFkT6kGppEm6PjIDhQB4HmrdzxHbolj95y37Zx6CsefaQyQ xahU65jzImb6I9yVlbqmsRaIV1ZK4BK15bSrjRf+wdsBI/ttB6DKBEtBRe0DJFtAx6ko ZcotXe1B6wFxStVylYj/UWLQq+PxJ01ex7PfDAA/odqk54fL5GJROJWHYW0df8WX5/zE /9AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VlN35XgI9PTndq7UxTnTEbK2ldcab2451jgEL0ZSqaM=; b=ttPil1USIaFx7RAPZJ1JaMVF2Y7SpJwwp0twIOqx8dmu333JUair4zeZorQ6LhFS6P xk/vrP8JXV3z8xbqKfcuvsmnjOPGk9iCTskNtWd7xGqkWTR5Ep0hinr4ogxUGc/xDiaj z0ZoU6NTbLpiDejBLa00WN+46M8b9WeRfSyfUtfLV54SP/EIEl4YFupvtiYFRim086i6 ztgVy0e/hzIUddnhvmGfuoZmmBdObGUPR7mvaa/DedSZDWeG0E9gSQWYChQcTqY0BLRB NljxOPrYy6ETjPZJrANJV/gCIs0o9ZfDkcKdZROP6Q5rySo8OFUxTOWAatCP4WEsYBHX t9rA== X-Gm-Message-State: AOAM533w4Hb5I0ayRRlKDHyXoVsPprcFd4JJCorvmYwBWIMx+zWMFMDu +xPjzGX7usIuuxq8MupOMkig5w== X-Google-Smtp-Source: ABdhPJwbY21FHjl+4IYmDViZ0w3nIjwM1u55QjVUR+U+sgXEVNyv2YYgx3yFKvEqpM+tyxZO17JJRQ== X-Received: by 2002:ac8:5cc5:: with SMTP id s5mr31197902qta.256.1634577902431; Mon, 18 Oct 2021 10:25:02 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id t24sm6891783qkj.38.2021.10.18.10.25.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Oct 2021 10:25:01 -0700 (PDT) Date: Mon, 18 Oct 2021 13:25:00 -0400 From: Johannes Weiner To: Matthew Wilcox Cc: Kent Overstreet , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 30C5EF000136 X-Stat-Signature: ac6xupycnuez5py1ek88iomw7mqkdqoq Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=qK2G14Y7; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf17.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.172 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-HE-Tag: 1634577903-21990 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 Sat, Oct 16, 2021 at 08:07:40PM +0100, Matthew Wilcox wrote: > On Wed, Sep 22, 2021 at 11:08:58AM -0400, Johannes Weiner wrote: > > mm/lru: Add folio LRU functions > > > > The LRU code is used by anon and file and not needed > > for the filesystem API. > > > > And as discussed, there is generally no ambiguity of > > tail pages on the LRU list. > > One of the assumptions you're making is that the current code is suitable > for folios. One of the things that happens in this patch is: > > - update_lru_size(lruvec, lru, page_zonenum(page), thp_nr_pages(page)); > + update_lru_size(lruvec, lru, folio_zonenum(folio), > + folio_nr_pages(folio)); > > static inline long folio_nr_pages(struct folio *folio) > { > return compound_nr(&folio->page); > } > > vs > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > static inline int thp_nr_pages(struct page *page) > { > VM_BUG_ON_PGFLAGS(PageTail(page), page); > if (PageHead(page)) > return HPAGE_PMD_NR; > return 1; > } > #else > static inline int thp_nr_pages(struct page *page) > { > VM_BUG_ON_PGFLAGS(PageTail(page), page); > return 1; > } > #endif > > So if you want to leave all the LRU code using pages, all the uses of > thp_nr_pages() need to be converted to compound_nr(). Or maybe not all > of them; I don't know which ones might be safe to leave as thp_nr_pages(). > That's one of the reasons I went with a whitelist approach. All of them. The only compound pages that can exist on the LRUs are THPs, and the only THP pages that can exist on the LRUs are compound. There is no plausible scenario where those two functions would disagree in the LRU code. Or elsewhere in the kernel, for that matter. Where would thp_nr_pages() returning compound_nr() ever be wrong? How else are we implementing THPs? I'm not sure that would make sense.