All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V (IBM) <aneesh.kumar@kernel.org>
To: Peter Xu <peterx@redhat.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	James Houghton <jthoughton@google.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Yang Shi <shy828301@gmail.com>, Rik van Riel <riel@surriel.com>,
	Hugh Dickins <hughd@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Mike Rapoport <rppt@kernel.org>,
	Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
Date: Fri, 24 Nov 2023 10:58:51 +0530	[thread overview]
Message-ID: <87zfz37m98.fsf@kernel.org> (raw)
In-Reply-To: <ZV-p7haI5SmIYACs@x1n>

Peter Xu <peterx@redhat.com> writes:

> On Thu, Nov 23, 2023 at 06:22:33PM +0000, Christophe Leroy wrote:
>> > For fast-gup I think the hugepd code is in use, however for walk_page_*
>> > apis hugepd code shouldn't be reached iiuc as we have the hugetlb specific
>> > handling (walk_hugetlb_range()), so anything within walk_pgd_range() to hit
>> > a hugepd can be dead code to me (but note that this "dead code" is good
>> > stuff to me, if one would like to merge hugetlb instead into generic mm).
>> 
>> Not sure what you mean here. What do you mean by "dead code" ?
>> A hugepage directory can be plugged at any page level, from PGD to PMD.
>> So the following bit in walk_pgd_range() is valid and not dead:
>> 
>> 		if (is_hugepd(__hugepd(pgd_val(*pgd))))
>> 			err = walk_hugepd_range((hugepd_t *)pgd, addr, next, walk, PGDIR_SHIFT);
>
> IMHO it boils down to the question on whether hugepd is only used in
> hugetlbfs.  I think I already mentioned that above, but I can be more
> explicit; what I see is that from higher stack in __walk_page_range():
>
> 	if (is_vm_hugetlb_page(vma)) {
> 		if (ops->hugetlb_entry)
> 			err = walk_hugetlb_range(start, end, walk);
> 	} else
> 		err = walk_pgd_range(start, end, walk);
>
> It means to me as long as the vma is hugetlb, it'll not trigger any code in
> walk_pgd_range(), but only walk_hugetlb_range().  Do you perhaps mean
> hugepd is used outside hugetlbfs?
>

walk_pgd_range also get called from walk_page_range_novma().
IIRC commit e17eae2b839937817d771e2f5d2b30e5e2b81bb7 added the hugepd
details to pagewalk code to handle ptdump.

There is also a desire to use hugepd format in vmap mappings. 
https://lore.kernel.org/linuxppc-dev/cover.1620795204.git.christophe.leroy@csgroup.eu

-aneesh

WARNING: multiple messages have this Message-ID (diff)
From: Aneesh Kumar K.V (IBM) <aneesh.kumar@kernel.org>
To: Peter Xu <peterx@redhat.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	James Houghton <jthoughton@google.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Yang Shi <shy828301@gmail.com>, Rik van Riel <riel@surriel.com>,
	Hugh Dickins <hughd@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Mike Rapoport <rppt@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
Date: Fri, 24 Nov 2023 10:58:51 +0530	[thread overview]
Message-ID: <87zfz37m98.fsf@kernel.org> (raw)
In-Reply-To: <ZV-p7haI5SmIYACs@x1n>

Peter Xu <peterx@redhat.com> writes:

> On Thu, Nov 23, 2023 at 06:22:33PM +0000, Christophe Leroy wrote:
>> > For fast-gup I think the hugepd code is in use, however for walk_page_*
>> > apis hugepd code shouldn't be reached iiuc as we have the hugetlb specific
>> > handling (walk_hugetlb_range()), so anything within walk_pgd_range() to hit
>> > a hugepd can be dead code to me (but note that this "dead code" is good
>> > stuff to me, if one would like to merge hugetlb instead into generic mm).
>> 
>> Not sure what you mean here. What do you mean by "dead code" ?
>> A hugepage directory can be plugged at any page level, from PGD to PMD.
>> So the following bit in walk_pgd_range() is valid and not dead:
>> 
>> 		if (is_hugepd(__hugepd(pgd_val(*pgd))))
>> 			err = walk_hugepd_range((hugepd_t *)pgd, addr, next, walk, PGDIR_SHIFT);
>
> IMHO it boils down to the question on whether hugepd is only used in
> hugetlbfs.  I think I already mentioned that above, but I can be more
> explicit; what I see is that from higher stack in __walk_page_range():
>
> 	if (is_vm_hugetlb_page(vma)) {
> 		if (ops->hugetlb_entry)
> 			err = walk_hugetlb_range(start, end, walk);
> 	} else
> 		err = walk_pgd_range(start, end, walk);
>
> It means to me as long as the vma is hugetlb, it'll not trigger any code in
> walk_pgd_range(), but only walk_hugetlb_range().  Do you perhaps mean
> hugepd is used outside hugetlbfs?
>

walk_pgd_range also get called from walk_page_range_novma().
IIRC commit e17eae2b839937817d771e2f5d2b30e5e2b81bb7 added the hugepd
details to pagewalk code to handle ptdump.

There is also a desire to use hugepd format in vmap mappings. 
https://lore.kernel.org/linuxppc-dev/cover.1620795204.git.christophe.leroy@csgroup.eu

-aneesh


  reply	other threads:[~2023-11-24  5:30 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16  1:28 [PATCH RFC 00/12] mm/gup: Unify hugetlb, part 2 Peter Xu
2023-11-16  1:28 ` [PATCH RFC 01/12] mm/hugetlb: Export hugetlbfs_pagecache_present() Peter Xu
2023-11-23  7:23   ` Christoph Hellwig
2023-11-23 16:05     ` Peter Xu
2023-11-16  1:28 ` [PATCH RFC 02/12] mm: Provide generic pmd_thp_or_huge() Peter Xu
2023-11-16  1:28 ` [PATCH RFC 03/12] mm: Export HPAGE_PXD_* macros even if !THP Peter Xu
2023-11-23  7:23   ` Christoph Hellwig
2023-11-23  9:53     ` Mike Rapoport
2023-11-23 15:27       ` Peter Xu
2023-11-16  1:29 ` [PATCH RFC 04/12] mm: Introduce vma_pgtable_walk_{begin|end}() Peter Xu
2023-11-23  7:24   ` Christoph Hellwig
2023-11-23 16:11     ` Peter Xu
2023-11-24  4:02   ` Aneesh Kumar K.V
2023-11-24 15:34     ` Peter Xu
2023-11-16  1:29 ` [PATCH RFC 05/12] mm/gup: Fix follow_devmap_p[mu]d() to return even if NULL Peter Xu
2023-11-23  7:25   ` Christoph Hellwig
2023-11-23 17:59     ` Peter Xu
2023-11-16  1:29 ` [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing Peter Xu
2023-11-16  1:29   ` Peter Xu
2023-11-20  8:26   ` Christoph Hellwig
2023-11-20  8:26     ` Christoph Hellwig
2023-11-21 15:59     ` Peter Xu
2023-11-21 15:59       ` Peter Xu
2023-11-22  8:00       ` Christoph Hellwig
2023-11-22  8:00         ` Christoph Hellwig
2023-11-22 15:22         ` Peter Xu
2023-11-22 15:22           ` Peter Xu
2023-11-23  7:21           ` Christoph Hellwig
2023-11-23  7:21             ` Christoph Hellwig
2023-11-23 16:10             ` Peter Xu
2023-11-23 16:10               ` Peter Xu
2023-11-23 18:22           ` Christophe Leroy
2023-11-23 18:22             ` Christophe Leroy
2023-11-23 19:37             ` Peter Xu
2023-11-23 19:37               ` Peter Xu
2023-11-24  5:28               ` Aneesh Kumar K.V [this message]
2023-11-24  5:28                 ` Aneesh Kumar K.V
2023-11-24  7:03               ` Christophe Leroy
2023-11-24  7:03                 ` Christophe Leroy
2023-11-24 18:16                 ` Peter Xu
2023-11-24 18:16                   ` Peter Xu
2023-11-24  1:06           ` Michael Ellerman
2023-11-24  1:06             ` Michael Ellerman
2023-11-23 15:47         ` Matthew Wilcox
2023-11-23 15:47           ` Matthew Wilcox
2023-11-23 17:22           ` Peter Xu
2023-11-23 17:22             ` Peter Xu
2023-11-23 19:11             ` Ryan Roberts
2023-11-23 19:11               ` Ryan Roberts
2023-11-23 19:46               ` Peter Xu
2023-11-23 19:46                 ` Peter Xu
2023-11-24  9:06                 ` Ryan Roberts
2023-11-24  9:06                   ` Ryan Roberts
2023-11-24 16:07                   ` Peter Xu
2023-11-24 16:07                     ` Peter Xu
2023-11-30 21:30                     ` Peter Xu
2023-11-30 21:30                       ` Peter Xu
2023-12-03 13:33                       ` Christophe Leroy
2023-12-03 13:33                         ` Christophe Leroy
2023-12-04 11:11                         ` Ryan Roberts
2023-12-04 11:11                           ` Ryan Roberts
2023-12-04 11:25                           ` Christophe Leroy
2023-12-04 11:25                             ` Christophe Leroy
2023-12-04 11:46                             ` Ryan Roberts
2023-12-04 11:46                               ` Ryan Roberts
2023-12-04 11:57                               ` Christophe Leroy
2023-12-04 11:57                                 ` Christophe Leroy
2023-12-04 12:02                                 ` Ryan Roberts
2023-12-04 12:02                                   ` Ryan Roberts
2023-12-04 16:48                           ` Peter Xu
2023-12-04 16:48                             ` Peter Xu
2023-11-16  1:29 ` [PATCH RFC 07/12] mm/gup: Refactor record_subpages() to find 1st small page Peter Xu
2023-11-16 14:51   ` Matthew Wilcox
2023-11-16 19:40     ` Peter Xu
2023-11-16 19:41       ` Matthew Wilcox
2023-11-16  1:29 ` [PATCH RFC 08/12] mm/gup: Handle hugetlb for no_page_table() Peter Xu
2023-11-16 14:58   ` kernel test robot
2023-11-23  7:26   ` Christoph Hellwig
2023-11-16  1:29 ` [PATCH RFC 09/12] mm/gup: Handle huge pud for follow_pud_mask() Peter Xu
2023-11-16 15:30   ` kernel test robot
2023-11-23  7:28   ` Christoph Hellwig
2023-11-23 16:19     ` Peter Xu
2023-11-16  1:29 ` [PATCH RFC 10/12] mm/gup: Handle huge pmd for follow_pmd_mask() Peter Xu
2023-11-16 15:53   ` kernel test robot
2023-11-16  1:29 ` [PATCH RFC 11/12] mm/gup: Handle hugepd for follow_page() Peter Xu
2023-11-16  1:29 ` [PATCH RFC 12/12] mm/gup: Merge hugetlb into generic mm code Peter Xu
2023-11-23  7:29   ` Christoph Hellwig
2023-11-23 16:21     ` Peter Xu
2023-11-22 14:51 ` [PATCH RFC 00/12] mm/gup: Unify hugetlb, part 2 Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfz37m98.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=david@redhat.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=jthoughton@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lstoakes@gmail.com \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=shy828301@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.