search for: folios

...> I'd really like to abstract hugetlb handling if possible. The way it stands > it's just very odd. There might be ways to make that better. I haven't really been looking too hard at making that special handling go away. > We'll need some reliable way to identify these folios that need care. > guest_memfd will be using folio->mapcount for now, so for now we couldn't > set a page type like hugetlb does. If hugetlb can set lru.next at a certain point, then guestmemfd could set a page type at a similar point, no? > > Also how does this translate to Mat...

On Thu, Jul 07, 2022 at 07:50:17PM -0700, Hugh Dickins wrote: > On Wed, 8 Jun 2022, Matthew Wilcox (Oracle) wrote: > > > Now that both callers have a folio, convert this function to > > take a folio & rename it. > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org> > > Reviewed-by: Christoph Hellwig <hch at lst.de> > >

On Thu, Jul 07, 2022 at 07:50:17PM -0700, Hugh Dickins wrote: > On Wed, 8 Jun 2022, Matthew Wilcox (Oracle) wrote: > > > Now that both callers have a folio, convert this function to > > take a folio & rename it. > > > > Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org> > > Reviewed-by: Christoph Hellwig <hch at lst.de> > >

Hi all, this series removes most users of the write_one_page API. These helpers internally call ->writepage which we are gradually removing from the kernel. Changes since v3: - drop all patches merged in v6.3-rc1 - re-add the jfs patch Changes since v2: - more minix error handling fixes Changes since v1: - drop the btrfs changes (queue up in the btrfs tree) - drop the finaly move to

...alph Campbell <rcampbell at nvidia.com> Reviewed-by: John Hubbard <jhubbard at nvidia.com> Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Cc: stable at vger.kernel.org --- Changes for v2: - Rebased to Linus master - Reworded commit message - Switched to using folios (thanks Matthew!) - Added Reviewed-by's --- mm/memory.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index f456f3b5049c..01a23ad48a04 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3563,8 +3563,21 @@ static vm_fault_t remove_de...

...thing to have an if ladder on the free path if we have only a couple > things. Certainly it looks good instead of doing overlaying tricks. I'd really like to abstract hugetlb handling if possible. The way it stands it's just very odd. We'll need some reliable way to identify these folios that need care. guest_memfd will be using folio->mapcount for now, so for now we couldn't set a page type like hugetlb does. > Also how does this translate to Matthew's memdesc world? guest_memfd and hugetlb would be operating on folios (at least for now), which contain the refc...

On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote: > On 12.11.24 06:26, Matthew Wilcox wrote: > > On Mon, Nov 11, 2024 at 08:26:54AM +0000, Fuad Tabba wrote: > > > Thanks for your comments Jason, and for clarifying my cover letter > > > David. I think David has covered everything, and I'll make sure to > > > clarify this in the cover letter

The patch titled Subject: fs/buffer: clean up block_commit_write has been added to the -mm mm-unstable branch. Its filename is fs-buffer-clean-up-block_commit_write.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-buffer-clean-up-block_commit_write.patch This patch will later appear in the mm-unstable branch

The patch titled Subject: fs: convert block_commit_write to return void has been added to the -mm mm-unstable branch. Its filename is fs-convert-block_commit_write-to-return-void.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/fs-convert-block_commit_write-to-return-void.patch This patch will later appear in the

On 08.11.24 18:05, Jason Gunthorpe wrote: > On Fri, Nov 08, 2024 at 04:20:30PM +0000, Fuad Tabba wrote: >> Some folios, such as hugetlb folios and zone device folios, >> require special handling when the folio's reference count reaches >> 0, before being freed. Moreover, guest_memfd folios will likely >> require special handling to notify it once a folio's reference >> count reaches...

One fix and a minor cleanup. Only compile-tested due to lack of HW, so I'd be happy if someone with access to HW could test. But not sure how easy this is to trigger. Likely some concurrent MADV_DONTNEED on the PTE we just converted might be able to trigger it. Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: Danilo Krummrich <dakr at

On 12.11.24 06:26, Matthew Wilcox wrote: > On Mon, Nov 11, 2024 at 08:26:54AM +0000, Fuad Tabba wrote: >> Thanks for your comments Jason, and for clarifying my cover letter >> David. I think David has covered everything, and I'll make sure to >> clarify this in the cover letter when I respin. > > I don't want you to respin. I think this is a bad idea. I'm

On Tue, Mar 28, 2023 at 01:14:34PM +1100, Alistair Popple wrote: > +++ b/mm/memory.c > @@ -3623,8 +3623,19 @@ static vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf) > struct vm_area_struct *vma = vmf->vma; > struct mmu_notifier_range range; > > - if (!folio_lock_or_retry(folio, vma->vm_mm, vmf->flags)) > + /* > + * We need a page reference to

On Mon, Nov 11, 2024 at 08:26:54AM +0000, Fuad Tabba wrote: > Thanks for your comments Jason, and for clarifying my cover letter > David. I think David has covered everything, and I'll make sure to > clarify this in the cover letter when I respin. I don't want you to respin. I think this is a bad idea.

...e accessor in hugetlb_cgroup.h. >> * @_hugetlb_cgroup_rsvd: Do not use directly, use accessor in hugetlb_cgroup.h. >> * @_hugetlb_hwpoison: Do not use directly, call raw_hwp_list_head(). >> + * @_hugetlb_list: To be used in hugetlb core code only. >> * @_deferred_list: Folios to be split under memory pressure. >> * @_unused_slab_obj_exts: Placeholder to match obj_exts in struct slab. >> * >> @@ -397,6 +398,17 @@ struct folio { >> }; >> struct page __page_2; >> }; >> + union { >> + struct { >> + unsigned l...

*** BLURB HERE *** Bean Huo (5): fs/buffer: clean up block_commit_write fs/buffer.c: convert block_commit_write to return void ext4: No need to check return value of block_commit_write() fs/ocfs2: No need to check return value of block_commit_write() udf: No need to check return value of block_commit_write() fs/buffer.c | 24 +++++++-----------------

Device exclusive page table entries are used to prevent CPU access to a page whilst it is being accessed from a device. Typically this is used to implement atomic operations when the underlying bus does not support atomic access. When a CPU thread encounters a device exclusive entry it locks the page and restores the original entry after calling mmu notifiers to signal drivers that exclusive

Hi Jason and David, On Fri, 8 Nov 2024 at 19:33, David Hildenbrand <david at redhat.com> wrote: > > On 08.11.24 18:05, Jason Gunthorpe wrote: > > On Fri, Nov 08, 2024 at 04:20:30PM +0000, Fuad Tabba wrote: > >> Some folios, such as hugetlb folios and zone device folios, > >> require special handling when the folio's reference count reaches > >> 0, before being freed. Moreover, guest_memfd folios will likely > >> require special handling to notify it once a folio's reference > &gt...

...39;t have individual refcounts; all the refcounts are actually I had stuck with using the page because none of this stuff (yet) supports compound pages anyway so we shouldn't see a tail page anyway. But point taken, I admit I need to find some time to get a deeper internalised understanding of folios than just s/page/folio. > ohh, and I really should have caught that too. I plead spending too much > time recently in a somewhat more driver-centric mindset, and failing to > mentally shift gears properly for this case. > > Sorry for missing that! > > thanks,

On 3/28/23 20:16, Matthew Wilcox wrote: ... >> + if (!get_page_unless_zero(vmf->page)) >> + return 0; > > From a folio point of view: what the hell are you doing here? Tail > pages don't have individual refcounts; all the refcounts are actually ohh, and I really should have caught that too. I plead spending too much time recently in a somewhat more driver-centric