On Wed, 24 Nov 2021 14:30:56 -0800 Dan Williams
wrote:
> It might end up colliding with some of the DAX cleanups that are
> brewing, but if that happens I might apply them to resolve conflicts
> and ask Andrew to drop them out of -mm. We can cross that bridge
> later.
Yep, not a problem.
On Wed, 20 Apr 2022 16:53:09 +0100 Joao Martins
wrote:
> A compound devmap is a dev_pagemap with @vmemmap_shift > 0 and it
> means that pages are mapped at a given huge page alignment and utilize
> uses compound pages as opposed to order-0 pages.
>
> Take advantage of the fact that most tail pa
On Tue, 13 Feb 2024 14:59:11 -0800 Suren Baghdasaryan wrote:
> > > If you think you can easily achieve what Michal requested without all
> > > that,
> > > good.
> >
> > He requested something?
>
> Yes, a cleaner instrumentation. Unfortunately the cleanest one is not
> possible until the compile
On Mon, 12 Feb 2024 13:38:59 -0800 Suren Baghdasaryan wrote:
> +Example output.
> +
> +::
> +
> +> cat /proc/allocinfo
> +
> + 153MiB mm/slub.c:1826 module:slub func:alloc_slab_page
> + 6.08MiB mm/slab_common.c:950 module:slab_common func:_kmalloc_order
> + 5.09MiB mm
On Wed, 20 Mar 2024 16:24:30 +1300 Barry Song <21cn...@gmail.com> wrote:
> Hi Stephen,
> Thanks for reviewing.
>
> On Wed, Mar 20, 2024 at 2:42 PM Stephen Rothwell
> wrote:
> >
> > Hi Barry,
> >
> > On Wed, 20 Mar 2024 13:16:56 +1300 Barry Song <21cn...@gmail.com> wrote:
> > >
> > > diff --git
On Thu, 21 Mar 2024 07:48:36 +1300 Barry Song <21cn...@gmail.com> wrote:
> > Stronger than that please. Just tell people not to use macros in such
> > situations. Always code it in C.
>
> While I appreciate the consistency of always using "static inline"
> instead of macros,
> I've noticed nume
On Thu, 21 Mar 2024 09:36:27 -0700 Suren Baghdasaryan wrote:
> From: Kent Overstreet
>
> We're introducing alloc tagging, which tracks memory allocations by
> callsite. Converting alloc_inode_sb() to a macro means allocations will
> be tracked by its caller, which is a bit more useful.
I'd hav
On Thu, 21 Mar 2024 09:36:22 -0700 Suren Baghdasaryan wrote:
> Low overhead [1] per-callsite memory allocation profiling. Not just for
> debug kernels, overhead low enough to be deployed in production.
>
> Example output:
> root@moria-kvm:~# sort -rn /proc/allocinfo
>12766412831168 mm/
On Thu, 21 Mar 2024 17:15:39 -0400 Kent Overstreet
wrote:
> On Thu, Mar 21, 2024 at 01:31:47PM -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2024 09:36:27 -0700 Suren Baghdasaryan
> > wrote:
> >
> > > From: Kent Overstreet
> > >
> > > We&#
On Fri, 2 Aug 2024 10:49:22 +0100 Jonathan Cameron
wrote:
> > --- a/mm/mm_init.c
> > +++ b/mm/mm_init.c
> > @@ -1838,11 +1838,10 @@ void __init free_area_init(unsigned long
> > *max_zone_pfn)
> >
> > if (!node_online(nid)) {
> > /* Allocator not initialized yet
On Mon, 19 Aug 2024 21:40:34 +0100 Matthew Wilcox wrote:
> On Mon, Aug 19, 2024 at 01:39:16PM -0700, Suren Baghdasaryan wrote:
> > On Mon, Aug 19, 2024 at 12:34 PM Matthew Wilcox wrote:
> > > So if ALLOC_TAG_REF_WIDTH is big enough, it's going to force last_cpupid
> > > into struct page.
> >
>
On Sun, 1 Sep 2024 21:41:28 -0700 Suren Baghdasaryan wrote:
> Add CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to store allocation tag
> references directly in the page flags. This removes dependency on
> page_ext and results in better performance for page allocations as
> well as reduced page_ext memory ov
On Sun, 1 Sep 2024 21:41:27 -0700 Suren Baghdasaryan wrote:
> Introduce CONFIG_PGALLOC_TAG_REF_BITS to control the size of the
> page allocation tag references. When the size is configured to be
> less than a direct pointer, the tags are searched using an index
> stored as the tag reference.
>
On Mon, 22 Jul 2019 17:32:04 -0400 "Joel Fernandes (Google)"
wrote:
> The page_idle tracking feature currently requires looking up the pagemap
> for a process followed by interacting with /sys/kernel/mm/page_idle.
> This is quite cumbersome and can be error-prone too. If between
> accessing the
(cc Brendan's other email address, hoping for review input ;))
On Mon, 5 Aug 2019 13:04:47 -0400 "Joel Fernandes (Google)"
wrote:
> The page_idle tracking feature currently requires looking up the pagemap
> for a process followed by interacting with /sys/kernel/mm/page_idle.
> Looking up PFN f
On Wed, 7 Aug 2019 06:00:13 -0400 Joel Fernandes wrote:
> > > 8 files changed, 376 insertions(+), 45 deletions(-)
> >
> > Quite a lot of new code unconditionally added to major architectures.
> > Are we confident that everyone will want this feature?
>
> I did not follow, could you clarify mor
On Wed, 7 Aug 2019 13:15:54 -0400 "Joel Fernandes (Google)"
wrote:
> In Android, we are using this for the heap profiler (heapprofd) which
> profiles and pin points code paths which allocates and leaves memory
> idle for long periods of time. This method solves the security issue
> with userspa
On Wed, 7 Aug 2019 16:45:30 -0400 Joel Fernandes wrote:
> On Wed, Aug 07, 2019 at 01:04:02PM -0700, Andrew Morton wrote:
> > On Wed, 7 Aug 2019 13:15:54 -0400 "Joel Fernandes (Google)"
> > wrote:
> >
> > > In Android, we are using this for the heap p
On Mon, 19 Aug 2019 17:28:51 +0100 Will Deacon wrote:
> On Thu, Aug 15, 2019 at 04:43:59PM +0100, Catalin Marinas wrote:
> > There isn't a good reason to differentiate between the user address
> > space layout modification syscalls and the other memory
> > permission/attributes ones (e.g. mprotec
(cc printk maintainers).
On Sun, 25 Aug 2019 01:37:23 +0200 Uwe Kleine-König
wrote:
> pr_info("probing failed (%dE)\n", ret);
>
> expands to
>
> probing failed (EIO)
>
> if ret holds -EIO (or EIO). This introduces an array of error codes. If
> the error code is missing, %dE fal
On Tue, 17 Sep 2019 08:59:59 +0200 Rasmus Villemoes
wrote:
> It has been suggested several times to extend vsnprintf() to be able
> to convert the numeric value of ENOSPC to print "ENOSPC". This is yet
> another attempt. Rather than adding another %p extension, simply teach
> plain %p to convert
On Fri, 31 May 2019 21:50:15 +0200 Albert Vaca Cintora
wrote:
> Adds a readonly 'current_inotify_watches' entry to the user sysctl table.
> The handler for this entry is a custom function that ends up calling
> proc_dointvec. Said sysctl table already contains 'max_inotify_watches'
> and it gets
On Tue, 2 Jul 2019 14:37:30 -0400 Waiman Long wrote:
> Currently, a value of '1" is written to /sys/kernel/slab//shrink
> file to shrink the slab by flushing all the per-cpu slabs and free
> slabs in partial lists. This applies only to the root caches, though.
>
> Extends this capability by shr
On Tue, 2 Jul 2019 16:44:24 -0400 Waiman Long wrote:
> On 7/2/19 4:03 PM, Andrew Morton wrote:
> > On Tue, 2 Jul 2019 14:37:30 -0400 Waiman Long wrote:
> >
> >> Currently, a value of '1" is written to /sys/kernel/slab//shrink
> >> file to shrink the
On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
> This is v5 of the patchset to improve how we're tracking and reporting
> errors that occur during pagecache writeback.
I'm curious to know how you've been testing this? Is that testing
strong enough for us to be confident that all nature o
On Wed, 31 May 2017 17:31:49 -0400 Jeff Layton wrote:
> On Wed, 2017-05-31 at 13:27 -0700, Andrew Morton wrote:
> > On Wed, 31 May 2017 08:45:23 -0400 Jeff Layton wrote:
> >
> > > This is v5 of the patchset to improve how we're tracking and reporting
> > &
On Thu, 30 Nov 2017 15:28:17 + Roman Gushchin wrote:
> This patchset makes the OOM killer cgroup-aware.
Thanks, I'll grab these.
There has been controversy over this patchset, to say the least. I
can't say that I followed it closely! Could those who still have
reservations please summaris
Cc: Michal Hocko
Cc: Johannes Weiner
Cc: Vladimir Davydov
Cc: Tetsuo Handa
Cc: David Rientjes
Cc: Tejun Heo
Cc: Michal Hocko
Signed-off-by: Andrew Morton
---
include/linux/memcontrol.h | 17 +++
include/linux/oom.h| 12 ++
mm/memcontrol.c| 181
On Wed, 10 Jan 2018 05:11:44 -0800 Roman Gushchin wrote:
> Hello, David!
>
> On Tue, Jan 09, 2018 at 04:57:53PM -0800, David Rientjes wrote:
> > On Thu, 30 Nov 2017, Andrew Morton wrote:
> >
> > > > This patchset makes the OOM killer cgroup-aware.
>
On Wed, 24 Jan 2018 13:44:02 -0800 (PST) David Rientjes
wrote:
> On Wed, 24 Jan 2018, Michal Hocko wrote:
>
> > > The current implementation of memory.oom_group is based on top of a
> > > selection implementation that is broken in three ways I have listed for
> > > months:
> >
> > This doesn
On Thu, 25 Jan 2018 15:53:48 -0800 (PST) David Rientjes
wrote:
> Now that each mem cgroup on the system has a memory.oom_policy tunable to
> specify oom kill selection behavior, remove the needless "groupoom" mount
> option that requires (1) the entire system to be forced, perhaps
> unnecessaril
On Fri, 26 Jan 2018 14:20:24 -0800 (PST) David Rientjes
wrote:
> On Thu, 25 Jan 2018, Andrew Morton wrote:
>
> > > Now that each mem cgroup on the system has a memory.oom_policy tunable to
> > > specify oom kill selection behavior, remove the needless "grou
On Fri, 26 Jan 2018 14:52:59 -0800 (PST) David Rientjes
wrote:
> On Fri, 26 Jan 2018, Andrew Morton wrote:
>
> > > -ECONFUSED. We want to have a mount option that has the sole purpose of
> > > doing echo cgroup > /mnt/cgroup/memory.oom_policy?
> >
> >
On Tue, 30 Jan 2018 13:20:11 +0100 Michal Hocko wrote:
> Subject: [PATCH] oom, memcg: clarify root memcg oom accounting
>
> David Rientjes has pointed out that the current way how the root memcg
> is accounted for the cgroup aware OOM killer is undocumented. Unlike
> regular cgroups there is no
On Mon, 12 Feb 2018 16:24:25 -0800 (PST) David Rientjes
wrote:
> Both kernelcore= and movablecore= can be used to define the amount of
> ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
> the system memory capacity to be known when specifying the command line,
> however.
>
On Tue, 13 Feb 2018 15:55:11 -0800 (PST) David Rientjes
wrote:
> >
> > Is this fine-grained enough? We've had percentage-based tunables in
> > the past, and 10 years later when systems are vastly larger, 1% is too
> > much.
> >
>
> They still have the (current) ability to define the exact am
ly occurred on the system.
> 32768 (K): The kernel has been live patched.
> 65536 (X): Auxiliary taint, defined and used by for distros.
> +131072 (T): The kernel was built with the struct randomization plugin.
Uncle.
From: Andrew Morton
Subject: Documentation/sysctl/kernel.txt: sh
On Wed, 21 Nov 2018 12:54:20 -0800 Daniel Colascione wrote:
> Trace analysis code needs a coherent picture of the set of processes
> and threads running on a system. While it's possible to enumerate all
> tasks via /proc, this enumeration is not atomic. If PID numbering
> rolls over during snapsh
On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascione wrote:
> On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton
> wrote:
> >
> > On Wed, 21 Nov 2018 12:54:20 -0800 Daniel Colascione
> > wrote:
> >
> > > Trace analysis code needs a coherent picture of
On Wed, 21 Nov 2018 15:21:40 -0800 Daniel Colascione wrote:
> On Wed, Nov 21, 2018 at 2:50 PM Andrew Morton
> wrote:
> >
> > On Wed, 21 Nov 2018 14:40:28 -0800 Daniel Colascione
> > wrote:
> >
> > > On Wed, Nov 21, 2018 at 2:12 PM Andrew Morton
>
On Wed, 21 Nov 2018 16:28:56 -0800 Daniel Colascione wrote:
> > > The problem here is the possibility of confusion, even if it's rare.
> > > Does the naive approach of just walking /proc and ignoring the
> > > possibility of PID reuse races work most of the time? Sure. But "most
> > > of the time
On Wed, 21 Nov 2018 17:08:08 -0800 Daniel Colascione wrote:
> Have you done much
> retrospective long trace analysis?
No. Have you?
Of course you have, which is why I and others are dependent upon you to
explain why this change is worth adding to Linux. If this thing solves
a problem which we
On Tue, 11 Dec 2018 16:00:19 + Will Deacon wrote:
> > Yes, that was the intention of sending v13. Should have I sent a
> > separate patch with v12->v13 fixes instead? I don't know what's the
> > usual way to make changes to the patchset once it's in the mm tree.
I usually convert replacement
On Fri, 14 Dec 2018 18:35:28 +0100 Jorge Ramirez-Ortiz
wrote:
> As per Documentation/process/submitting-patches, Co-developed-by is a
> valid signature.
>
I'm with Joe - I find this tag kinda useless and duplicative. But whatever.
But as the documentation says, Co-developed-by must be accomp
On Mon, 17 Dec 2018 20:33:42 +0100 Andrey Konovalov
wrote:
> > Curiosity, did you try your patches with SLUB red zoning enabled?
> > Since the area used for the Redzone is just after the payload, aligning the
> > object_size independently from the allocator could have side effects, at
> > least
On Tue, 18 Dec 2018 14:30:33 +0100 Andrey Konovalov
wrote:
> Instead of changing cache->align to be aligned to KASAN_SHADOW_SCALE_SIZE
> in kasan_cache_create() we can reuse the ARCH_SLAB_MINALIGN macro.
>
> ...
>
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
> @
On Wed, 2 Jan 2019 18:36:06 +0100 Andrey Konovalov
wrote:
> Instead of changing cache->align to be aligned to KASAN_SHADOW_SCALE_SIZE
> in kasan_cache_create() we can reuse the ARCH_SLAB_MINALIGN macro.
>
> ...
>
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
> @
On Fri, 8 Feb 2019 13:45:47 +0200 Mike Rapoport wrote:
> * Remove comments mentioning bootmem
> * Extend "DOC: memblock overview"
> * Add kernel-doc comments for several more functions
>
> ...
>
> @@ -1400,6 +1413,19 @@ phys_addr_t __init
> memblock_phys_alloc_range(phys_addr_t size,
> r
On Mon, 16 Oct 2017 17:19:15 +0800 changbin...@intel.com wrote:
> The first one introduce new interfaces, the second one kills naming confusion.
> The aim is to remove duplicated code and simplify transparent huge page
> allocation.
These introduce various allnoconfig build errors.
--
To unsubscr
On Mon, 17 Oct 2016 14:55:37 -0200 Mauro Carvalho Chehab
wrote:
> This patch series continues the efforts of converting the Linux Kernel
> documentation to Sphinx.
hm, renaming Documentation/kernel-parameters.txt in linux-next is going
to be a pain for the next two months. I have one large pat
On Wed, 16 Dec 2015 10:27:57 -0500 Tejun Heo wrote:
> On Wed, Dec 16, 2015 at 08:47:35AM +0100, Richard Weinberger wrote:
> > > Andrew? Are you or anyone else interested in picking up this patchset?
> >
> > I know I'm repeating myself. But this should be done in userspace.
>
> Nothing in this
On Wed, 6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov wrote:
> This patchset continues the work I started with:
>
> commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
> Author: Vitaly Kuznetsov
> Date: Tue Mar 15 14:56:48 2016 -0700
>
> memory-hotplug: add automatic onlining policy for the ne
t you have now?
Sure.
That Documentation/vm/transhuge.txt paragraph isn't in great shape so
I gave it some extra help.
From: Eric Engestrom
Subject: Documentation: vm: fix spelling mistakes
Signed-off-by: Eric Engestrom
Cc: Jonathan Corbet
Signed-off-by: Andrew Morton
---
Documen
On Thu, 23 Jun 2016 18:07:10 +0300 Topi Miettinen wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
> Currently, there is no
On Mon, 11 Jul 2016 11:17:21 +0100 Kieran Bingham
wrote:
> Will this fixes series be able to make it for 4.7 ?
Yup, I'll send them in this week. Sorry, I've been a bit laggy the
past two weeks. Back up to speed now though.
--
To unsubscribe from this list: send the line "unsubscribe linux-do
On Wed, 20 Jul 2016 17:13:02 -0600 Jonathan Corbet wrote:
> On Thu, 14 Jul 2016 15:40:48 -0600
> Ross Zwisler wrote:
>
> > These are originally from Matthew Wilcox and were part of his huge
> > "mm,fs,dax: Change ->pmd_fault to ->huge_fault" patch that was part of PUD
> > support.
> >
> > I'm
On Mon, 1 Aug 2016 19:59:47 -0300 Mauricio Faria de Oliveira
wrote:
> This patchset introduces dma_attr DMA_ATTR_NO_WARN (just like __GFP_NOWARN),
> which tells the DMA-mapping subsystem to suppress allocation failure reports.
>
> On some architectures allocation failures are reported with err
On Thu, 4 Aug 2016 21:17:27 -0300 Mauricio Faria de Oliveira
wrote:
> > [snip] An alternative (and more idiomatic) fix would be to
> > change the blk_rq_map_sg() interface to permit passing down some
> > foo_NOWARN flag and propagating that down the stack into
> > ppc_iommu_map_sg(). Was this a
On Fri, 5 Aug 2016 09:34:20 -0300 Mauricio Faria de Oliveira
wrote:
> On 08/04/2016 10:05 PM, Andrew Morton wrote:
> > Of course, the alternative is to just delete the damn warnings from
> > ppc_iommu_map_sg(). Imagine that! Have they ever been of any use to
> > anyone?
&
On Mon, 11 Jan 2016 09:30:22 -0800 Douglas Anderson
wrote:
> This series of patches will speed up memory allocation in dma-mapping
> quite a bit.
This is pretty much all ARM and driver stuff so I think I'll duck it.
But I can merge it if nobody else feels a need to.
I saw a few acked-by/teste
On Mon, 14 Oct 2024 07:57:00 +0500 Sabyrzhan Tasbolatov
wrote:
> Migrate the copy_user_test to the KUnit framework to verify out-of-bound
> detection via KASAN reports in copy_from_user(), copy_to_user() and
> their static functions.
>
> This is the last migrated test in kasan_test_module.c, th
On Mon, 14 Oct 2024 13:36:41 -0700 Suren Baghdasaryan wrote:
> Patch #2 copies module tags into virtually contiguous memory which
> serves two purposes:
> - Lets us deal with the situation when module is unloaded while there
> are still live allocations from that module. Since we are using a copy
On Mon, 14 Oct 2024 13:36:43 -0700 Suren Baghdasaryan wrote:
> When a module gets unloaded there is a possibility that some of the
> allocations it made are still used and therefore the allocation tags
> corresponding to these allocations are still referenced. As such, the
> memory for these tags
On Wed, 23 Oct 2024 10:07:58 -0700 Suren Baghdasaryan wrote:
> To simplify later changes to page tag references, introduce new
> pgtag_ref_handle type. This allows easy replacement of page_ext
> as a storage of page allocation tags.
>
> ...
>
> static inline void pgalloc_tag_copy(struct folio *
On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple wrote:
> Device and FS DAX pages have always maintained their own page
> reference counts without following the normal rules for page reference
> counting. In particular pages are considered free when the refcount
> hits one rather than zero and
On Mon, 16 Dec 2024 11:55:30 +1100 Alistair Popple wrote:
> The remainder are more -mm focussed. However they do depend on the fs/dax
> cleanups in the first half so the trick would be making sure Andrew only takes
> them if the nvdimm.git changes have made it into -next. I'm happy with either
>
On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams wrote:
> > - Remove PTE_DEVMAP definitions from Loongarch which were added since
> >this series was initially written.
> [..]
> >
> > base-commit: e25c8d66f6786300b680866c0e0139981273feba
>
> If this is going to go through nvdimm.git I will ne
On Fri, 28 Feb 2025 14:42:40 +1100 Alistair Popple wrote:
> This is essentially the same as what's currently in mm-unstable aside from
> the two updates listed below. The main thing to note is it incorporates
> Balbir's fixup which is currently in mm-unstable as c98612955016
> ("mm-allow-compound
68 matches
Mail list logo
