On Wed, 16 Jul 2025 10:47:29 +0200 David Hildenbrand wrote:
> >
> > However the series rejects due to the is_huge_zero_pmd ->
> > is_huge_zero_pfn changes in Luiz's "mm: introduce snapshot_page() v3"
> > series, so could we please have a redo against present mm-new?
>
> I'm confused: mm-new *st
On Tue, 15 Jul 2025 15:23:41 +0200 David Hildenbrand wrote:
> Based on mm/mm-new. I dropped the CoW PFNMAP changes for now, still
> working on a better way to sort all that out cleanly.
>
> Cleanup and unify vm_normal_page_*() handling, also marking the
> huge zerofolio as special in the PMD. Ad
On Sun, 4 May 2025 08:47:45 +0200 David Hildenbrand wrote:
> >
> > Methinks max_nr really wants to be unsigned long.
>
> We only batch within a single PTE table, so an integer was sufficient.
>
> The unsigned value is the result of a discussion with Ryan regarding
> similar/related
> (rmap)
On Fri, 2 May 2025 23:50:19 +0200 Petr Vaněk wrote:
> On XEN PV, folio_pte_batch() can incorrectly batch beyond the end of a
> folio due to a corner case in pte_advance_pfn(). Specifically, when the
> PFN following the folio maps to an invalidated MFN,
>
> expected_pte = pte_advance_pfn(e
On Thu, 10 Apr 2025 16:50:33 +0200 Alexander Gordeev
wrote:
> On Tue, Apr 08, 2025 at 06:07:32PM +0200, Alexander Gordeev wrote:
>
> Hi Andrew,
>
> > The lazy MMU mode can only be entered and left under the protection
> > of the page table locks for all page tables which may be modified.
>
>
On Mon, 7 Apr 2025 17:11:26 +0200 Alexander Gordeev
wrote:
> This series is an attempt to fix the violation of lazy MMU mode context
> requirement as described for arch_enter_lazy_mmu_mode():
>
> This mode can only be entered and left under the protection of
> the page table locks for
On Fri, 14 Mar 2025 15:37:54 -0600 Nico Pache wrote:
> Add NR_BALLOON_PAGES counter to track memory used by balloon drivers and
> expose it through /proc/meminfo and other memory reporting interfaces.
>
> ...
>
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -162,6 +162,8 @@ static int
On Fri, 20 Dec 2024 17:26:38 +0800 Guo Weikang
wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `mem
On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan
wrote:
> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace
On Tue, 10 Dec 2024 18:41:29 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 18:31:30 -0800 Andrew Morton wrote:
> > > > I'll just grab everything and see if anyone complains ;)
> > >
> > > I may, if this leads to a conflict :(
> >
> > Ve
On Tue, 10 Dec 2024 17:35:48 -0800 Jakub Kicinski wrote:
> On Tue, 10 Dec 2024 15:36:04 -0800 Andrew Morton wrote:
> > > I have the same question as before: How do you expect these to land?
> > > Do you now have a maintainer who will take all of them?
> > > Or do y
On Tue, 10 Dec 2024 22:02:31 + Easwar Hariharan
wrote:
> This is a series that follows up on my previous series to introduce
> secs_to_jiffies() and convert a few initial users.
Thanks, I added this to mm.git. I suppressed the usual added-to-mm
emails because s many cc's!
I'd ask rele
On Tue, 10 Dec 2024 15:14:22 -0800 Jeff Johnson
wrote:
> On 12/10/2024 2:02 PM, Easwar Hariharan wrote:
> > This is a series that follows up on my previous series to introduce
> > secs_to_jiffies() and convert a few initial users.[1] In the review for
> > that series, Anna-Maria requested conver
afaict we're in decent state to move this series into mm-stable. I've
tagged the following issues:
https://lkml.kernel.org/r/80532f73e52e2c21fdc9aac7bce24aefb76d11b0.ca...@linux.intel.com
https://lkml.kernel.org/r/30b5d493-b7c2-4e63-86c1-dcc73d21d...@redhat.com
Have these been addressed and are
On Tue, 11 Jun 2024 11:42:56 +0200 David Hildenbrand wrote:
> > We'll leave the ZONE_DEVICE case alone for now.
> >
>
> @Andrew, can we add here:
>
> "Note that self-hosted vmemmap pages will no longer be marked as
> reserved. This matches ordinary vmemmap pages allocated from the buddy
> du
On Tue, 11 Jun 2024 12:06:56 +0200 David Hildenbrand wrote:
> On 07.06.24 11:09, David Hildenbrand wrote:
> > In preparation for further changes, let's teach __free_pages_core()
> > about the differences of memory hotplug handling.
> >
> > Move the memory hotplug specific handling from generic_o
On Thu, 7 Apr 2022 14:06:37 +0200 Juergen Gross wrote:
> Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from
> zones with pages managed by the buddy allocator")
Six years ago!
> only zones with free
> memory are included in a built zonelist. This is problematic when e.g.
> a
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It was
On Tue, 11 Aug 2020 11:44:46 +0200 Roger Pau Monne wrote:
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
Acked-by: Andrew Morton .
Please add it to the Xen tree when appropriate.
(I'm not sure what David means by "sep
On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand wrote:
> >
> > Why does the firmware map support hotplug entries?
>
> I assume:
>
> The firmware memmap was added primarily for x86-64 kexec (and still, is
> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
> get hotp
On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
> This series have been in -next for some days, could we get this in
> mainline?
It's been in -next for two months?
> Andrew, do you have plan about them, maybe next release?
They're all reviewed except for "xen/balloon: mark inflated pages
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS wrote:
> On 2018-10-22 16:03, Arun KS wrote:
> > On 2018-10-19 13:37, Michal Hocko wrote:
> >> On Thu 18-10-18 19:18:25, Andrew Morton wrote:
> >> [...]
> >>> So this patch needs more work, yes?
> >>
&g
On Thu, 11 Oct 2018 09:55:03 +0200 Michal Hocko wrote:
> > > > > This is now not called anymore, although the xen/hv variants still do
> > > > > it. The function seems empty these days, maybe remove it as a followup
> > > > > cleanup?
> > > > >
> > > > > > - __online_page_increment_counters(pag
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to som
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that f
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
ion of function
> >> 'xen_pv_domain' [-Werror=implicit-function-declaration]
> if (xen_pv_domain())
> ^
I think I already fixed this.
From: Andrew Morton
Subject: mm-dont-defer-struct-page-initialization-for-xen-pv-guests-fix
explicitly include xen.
On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -347,6 +347,9 @@ static inline bool update_defer_init(pg_data_t *pgdat,
> /* Always populate low zones for address-constrained allocations */
> if (zone_end < pgdat_end_pfn(pgd
On Fri, 16 Feb 2018 16:41:01 +0100 Juergen Gross wrote:
> Commit f7f99100d8d95dbcf09e0216a143211e79418b9f ("mm: stop zeroing
> memory during allocation in vmemmap") broke Xen pv domains in some
> configurations, as the "Pinned" information in struct page of early
> page tables could get lost. Thi
30 matches
Mail list logo
