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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41075ECAAD3 for ; Thu, 1 Sep 2022 18:33:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 881928003D; Thu, 1 Sep 2022 14:33:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8316D8000D; Thu, 1 Sep 2022 14:33:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F9398003D; Thu, 1 Sep 2022 14:33:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 608228000D for ; Thu, 1 Sep 2022 14:33:14 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2B8901205B3 for ; Thu, 1 Sep 2022 18:33:14 +0000 (UTC) X-FDA: 79864363908.20.830DFC9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 97C30180074 for ; Thu, 1 Sep 2022 18:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=B7YWWxgdwGX8fRegL9+nqJ6tES+1V/k9HDc5eItCkcg=; b=pSQXXM1gehMmdnG/Cim3BGcgZl eQCMHcBzm9rbMcB9oUMUo3PHghTlt9WYtJ40Ff33BGnGch3Sa59pqeIyDvy6ian+lHYPvcbaoqqw0 nePch6kTIX+Ymk2gdMOkjyKGRr/gHm1N7XC/KyE0cbul6hGhPYj+fX1xteafiNP1osAl1gCbA2lIv /+0wv+4Xyq9v/CsNZIMI6amJN4fCk8DLdHCLe6WcT14vpKlee/LGZtbSlH4ohWbTzF0vmHUh9gD9q 0EIwHhJnDUvu0dZnGFIzDT1eoo7RIm89rqJ7ikdZ6ATm4NT71UocMO+80/wHw/N90MSZqtmPagt1D ki9OgsjQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTozr-006GDQ-H9; Thu, 01 Sep 2022 18:32:59 +0000 Date: Thu, 1 Sep 2022 19:32:59 +0100 From: Matthew Wilcox To: Mike Kravetz Cc: Sidhartha Kumar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, songmuchun@bytedance.com, vbabka@suse.cz, william.kucharski@oracle.com, dhowells@redhat.com, peterx@redhat.com, arnd@arndb.de, ccross@google.com, hughd@google.com, ebiederm@xmission.com Subject: Re: [PATCH 2/7] mm: add private field of first tail to struct page and struct folio Message-ID: References: <20220829230014.384722-1-sidhartha.kumar@oracle.com> <20220829230014.384722-3-sidhartha.kumar@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662057193; a=rsa-sha256; cv=none; b=wmmDYfyMLTu+ML3+6wDT7z2y7t6Pfwcxz+80KZq5fbzUHh6gNYihha51MbaIlvlQ/5N0HO s4fmwiD31cdxYym3UqDyz0YG01J2YR66ih1Yx3TNVHKyz6HTYXrv7MHv0YAsb9Lo2BR5eS zCWUm3IRtFJ9ci369GGa5zDwXsligMA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pSQXXM1g; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662057193; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=B7YWWxgdwGX8fRegL9+nqJ6tES+1V/k9HDc5eItCkcg=; b=HTk7XQbax6TCPuS3iXDM9k73xwNtGyrpffFSDAj4xZAfDmv92N+/b7vcY0IlCRy0TBpt58 EAHBLo2FFKKfiB9QwTGpoTe3mi8inCe+kK51Y2UGYpyDnPjr97pIr2ngrBY9eec+g4N2GX wa/mySzNxg21MgdUBvu4Vqj1Kyjp7Dk= X-Stat-Signature: 1pc4zx9o96yjzjhmr16j6w8w6o53doad X-Rspamd-Queue-Id: 97C30180074 X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pSQXXM1g; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam08 X-HE-Tag: 1662057192-713874 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, Sep 01, 2022 at 10:32:43AM -0700, Mike Kravetz wrote: > Not really an issue with this patch, but it made me read more of this > comment about folios. It goes on to say ... > > * same power-of-two. It is at least as large as %PAGE_SIZE. If it is > * in the page cache, it is at a file offset which is a multiple of that > * power-of-two. It may be mapped into userspace at an address which is > * at an arbitrary page offset, but its kernel virtual address is aligned > * to its size. > */ > > This series is to begin converting hugetlb code to folios. Just want to > note that 'hugetlb folios' have specific user space alignment restrictions. > So, I do not think the comment about arbitrary page offset would apply to > hugetlb. > > Matthew, should we note that hugetlb is special in the comment? Or, is it > not worth updating? I'm open to updating it if we can find good wording. What I'm trying to get across there is that when dealing with folios, you can assume that they're naturally aligned physically, logically (in the file) and virtually (kernel address), but not necessarily virtually (user address). Hugetlb folios are special in that they are guaranteed to be virtually aligned in user space, but I don't know if here is the right place to document that. It's an additional restriction, so code which handles generic folios doesn't need to know it. > Also, folio_get_private_1 will be used for the hugetlb subpool pointer > which resides in page[1].private. This is used in the next patch of > this series. I'm sure you are aware that hugetlb also uses page private > in sub pages 2 and 3. Can/will/should this method of accessing private > in sub pages be expanded to cover these as well? Expansion can happen > later, but if this can not be expanded perhaps we should come up with > another scheme. There's a few ways of tackling this. What I'm currently thinking is that we change how hugetlbfs uses struct page to store its extra data. It would end up looking something like this (in struct page): +++ b/include/linux/mm_types.h @@ -147,9 +147,10 @@ struct page { }; struct { /* Second tail page of compound page */ unsigned long _compound_pad_1; /* compound_head */ - unsigned long _compound_pad_2; /* For both global and memcg */ struct list_head deferred_list; + unsigned long hugetlbfs_private_2; + unsigned long hugetlbfs_private_3; }; struct { /* Page table pages */ unsigned long _pt_pad_1; /* compound_head */ although we could use better names and/or types? I haven't looked to see what you're storing here yet. And then we can make the corresponding change to struct folio to add these elements at the right place. Does that sound sensible?