of making cma_release()
non-blocking, for performance reasons
rfc:
https://lkml.org/lkml/2020/10/16/1050
Roman Gushchin (2):
mm: cma: introduce cma_release_nowait()
mm: hugetlb: don't drop hugetlb_lock around cma_release() call
include/linux/cma.h | 2 +
mm/cma.c| 93
that subsequent cma_alloc() call will pass, cma_alloc()
flushes the cma_release_wq workqueue. To avoid a performance
regression in the case when only cma_release() is used, gate it
by a per-cma area flag, which is set by the first call
of cma_release_nowait().
Signed-off-by: Roman Gushchin
02cc0a000 CR4:
> > 06f0
> > [9.845319] Call Trace:
> > [9.845429] __memcg_kmem_uncharge (mm/memcontrol.c:3022)
> > [9.845582] drain_obj_stock (./include/linux/rcupdate.h:689
> > mm/memcontrol.c:3114)
> > [9.845684] drain_local_stock (mm/memcontrol
On Thu, Oct 22, 2020 at 09:42:11AM -0700, Mike Kravetz wrote:
> On 10/21/20 7:33 PM, Roman Gushchin wrote:
> > On Wed, Oct 21, 2020 at 05:15:53PM -0700, Mike Kravetz wrote:
> >> On 10/16/20 3:52 PM, Roman Gushchin wrote:
> >>> This small patchset makes cma_release
On Thu, Oct 22, 2020 at 09:54:53AM +0800, Xiaqing (A) wrote:
>
>
> On 2020/10/17 6:52, Roman Gushchin wrote:
>
> > This small patchset makes cma_release() non-blocking and simplifies
> > the code in hugetlbfs, where previously we had to temporarily drop
> > huget
On Wed, Oct 21, 2020 at 05:15:53PM -0700, Mike Kravetz wrote:
> On 10/16/20 3:52 PM, Roman Gushchin wrote:
> > This small patchset makes cma_release() non-blocking and simplifies
> > the code in hugetlbfs, where previously we had to temporarily drop
> > hugetlb_lock around t
On Tue, Oct 20, 2020 at 09:56:51AM -0700, Shakeel Butt wrote:
> On Tue, Oct 20, 2020 at 6:49 AM Richard Palethorpe
> wrote:
> >
> > Hello,
> >
> > Richard Palethorpe writes:
> >
> > > Hello Shakeel,
> > >
> > > Shakeel Butt writes:
> > >>>
> > >>> V3: Handle common case where use_hierarchy=1
On Tue, Oct 20, 2020 at 02:18:22PM -0400, Johannes Weiner wrote:
> On Tue, Oct 20, 2020 at 10:07:17AM -0700, Roman Gushchin wrote:
> > If we want these counter to function properly, then we should go into the
> > opposite
> > direction and remove the special handling of t
On Tue, Oct 20, 2020 at 09:55:38AM -0700, Shakeel Butt wrote:
> On Mon, Oct 19, 2020 at 3:28 PM Roman Gushchin wrote:
> >
> > On Fri, Oct 16, 2020 at 07:15:02PM +0200, Michal Koutny wrote:
> > > On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner
> >
On Tue, Oct 20, 2020 at 06:27:14PM +0200, Michal Koutny wrote:
> Hi.
>
> On Mon, Oct 19, 2020 at 03:28:45PM -0700, Roman Gushchin wrote:
> > Currently the root memory cgroup is never charged directly, but
> > if an ancestor cgroup is charged, the charge is propagated u
good way to estimate the memory cgroup overhead.
How about the patch below, which consistently avoids charging the root
memory cgroup? It seems like it doesn't add too many checks.
Thanks!
--
>From f50ea74d8f118b9121da3754acdde630ddc060a7 Mon Sep 17 00:00:00 2001
From: Roman Gushchin
Date
cma_release() now is a non-blocking function, so there is no more need
to drop hugetlb_lock to call it.
Signed-off-by: Roman Gushchin
---
mm/hugetlb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index fe76f8fd5a73..c8c892b1cabc 100644
--- a/mm/hugetlb.c
-allocations are usually not that
frequent, a single global workqueue is used.
Signed-off-by: Roman Gushchin
---
mm/cma.c | 51 +--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 7f415d7cda9f..523cd9356bc7 100644
functions
in the kernel: most of them are non-blocking.
Roman Gushchin (2):
mm: cma: make cma_release() non-blocking
mm: hugetlb: don't drop hugetlb_lock around cma_release() call
mm/cma.c | 51 +--
mm/hugetlb.c | 6 --
2 files changed, 49
On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner wrote:
> On Fri, Oct 16, 2020 at 11:47:02AM +0200, Michal Koutný wrote:
> > Hello.
> >
> > On Wed, Oct 14, 2020 at 08:07:49PM +0100, Richard Palethorpe
> > wrote:
> > > SLAB objects which outlive their memcg are moved to their parent
> >
.h:2122
> kernel/rcu/tree_plugin.h:2157 kernel/rcu/tree.c:2661)
> ...
> Reported-By: l...@lists.linux.it
> Signed-off-by: Richard Palethorpe
> Cc: Johannes Weiner
> Cc: Roman Gushchin
> Cc: Andrew Morton
> Cc: Shakeel Butt
> Cc: Christoph Lameter
> Cc: Michal Hocko
> Cc: Tejun Heo
> Cc: Vlastimil Babka
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
Acked-by: Roman Gushchin
Thanks!
the mod_objcg_state()
> from int to enum node_stat_item.
>
> Signed-off-by: Muchun Song
Acked-by: Roman Gushchin
Thanks!
On Mon, Oct 12, 2020 at 09:03:26AM +0530, Bharata B Rao wrote:
> On Fri, Oct 09, 2020 at 11:45:51AM -0700, Roman Gushchin wrote:
> > On Fri, Oct 09, 2020 at 11:34:23AM +0530, Bharata B Rao wrote:
> >
> > Hi Bharata,
> >
> > > Object cgroup chargin
On Tue, Oct 13, 2020 at 07:05:50AM +0800, Philip Li wrote:
> On Fri, Oct 02, 2020 at 10:55:06AM -0700, Roman Gushchin wrote:
> > On Fri, Oct 02, 2020 at 01:34:06PM +0800, Philip Li wrote:
> > > On Thu, Oct 01, 2020 at 05:55:59PM -0700, Roman Gushchin wrote:
> > > >
On Fri, Oct 09, 2020 at 11:34:23AM +0530, Bharata B Rao wrote:
Hi Bharata,
> Object cgroup charging is done for all the objects during
> allocation, but during freeing, uncharging ends up happening
> for only one object in the case of bulk allocation/freeing.
Yes, it's definitely a problem.
On Mon, Oct 05, 2020 at 08:33:44PM +0200, David Hildenbrand wrote:
> On 05.10.20 20:25, Roman Gushchin wrote:
> > On Mon, Oct 05, 2020 at 07:27:47PM +0200, David Hildenbrand wrote:
> >> On 05.10.20 19:16, Roman Gushchin wrote:
> >>> On Mon, Oct 05, 2020 at
On Mon, Oct 05, 2020 at 07:27:47PM +0200, David Hildenbrand wrote:
> On 05.10.20 19:16, Roman Gushchin wrote:
> > On Mon, Oct 05, 2020 at 11:03:56AM -0400, Zi Yan wrote:
> >> On 2 Oct 2020, at 4:30, David Hildenbrand wrote:
> >>
> >>> On 02.10.20 10:10, Mic
On Mon, Oct 05, 2020 at 11:03:56AM -0400, Zi Yan wrote:
> On 2 Oct 2020, at 4:30, David Hildenbrand wrote:
>
> > On 02.10.20 10:10, Michal Hocko wrote:
> >> On Fri 02-10-20 09:50:02, David Hildenbrand wrote:
> >> - huge page sizes controllable by the userspace?
> >
> > It might be
On Mon, Oct 05, 2020 at 04:55:53PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 05, 2020 at 11:03:56AM -0400, Zi Yan wrote:
> > On 2 Oct 2020, at 4:30, David Hildenbrand wrote:
> > > Yes, I think one important feature would be that we don't end up placing
> > > a gigantic page where only a handful
On Fri, Oct 02, 2020 at 01:34:06PM +0800, Philip Li wrote:
> On Thu, Oct 01, 2020 at 05:55:59PM -0700, Roman Gushchin wrote:
> > On Fri, Oct 02, 2020 at 08:08:40AM +0800, kbuild test robot wrote:
> > > Hi Roman,
> > >
> > > Thank you for the patch! Yet some
On Fri, Oct 02, 2020 at 09:01:14AM +0200, Bastian Bittorf wrote:
> On Thu, Oct 01, 2020 at 01:39:31PM -0700, Roman Gushchin wrote:
> > > # Processor type and features
> > > #
> > > # CONFIG_ZONE_DMA is not set
> > > # CONFIG_SMP is not set
> >
> &
ULL.
page_memcg() contains a VM_BUG_ON_PAGE() check for the page not
being a slab page.
To make sure nobody uses a direct access, struct page's
mem_cgroup/obj_cgroups is converted to unsigned long memcg_data.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
---
fs/buffer.c |
MemcgKmem() and an open-coded OR operation setting the memcg
pointer with the MEMCG_DATA_KMEM bit. __ClearPageKmemcg() can be
simple deleted, as the whole memcg_data is zeroed at once.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
Acked-by:
, struct obj_cgroup **objcgs);
They are similar to the corresponding API for generic pages, except
that the setter can return false, indicating that the value has been
already set from a different thread.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
---
include/linux/memcontrol.h
ght be added later.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index c7ac0a5b8989..99a4841d658b 100
xed comments, by Shakeel
- added some VM_BUG_ON() checks
- fixed the debug output format of page->memcg_data
Roman Gushchin (4):
mm: memcontrol: use helpers to read page's memcg data
mm: memcontrol/slab: use helpers to access slab page's memcg_data
mm: introduce page memcg flags
mm: convert p
troller patches.
Thanks!
>
> url:
> https://github.com/0day-ci/linux/commits/Roman-Gushchin/mm-memcg-slab-fix-slab-statistics-in-SMP-configuration/20201002-044114
> base: git://git.cmpxchg.org/linux-mmotm.git master
> config: i386-randconfig-s002-20200930 (attached as .con
On Thu, Oct 01, 2020 at 02:59:50PM -0400, Johannes Weiner wrote:
> On Thu, Oct 01, 2020 at 11:27:39AM -0700, Roman Gushchin wrote:
> > On Thu, Oct 01, 2020 at 09:46:38AM -0400, Johannes Weiner wrote:
> > > On Wed, Sep 30, 2020 at 05:27:07PM -0700, Ro
On Thu, Oct 01, 2020 at 12:58:36PM -0700, Linus Torvalds wrote:
> On Thu, Oct 1, 2020 at 12:56 PM Roman Gushchin wrote:
> >
> > Bastian, can you, please, share your config?
>
> Bastian actually did that in the original email, but that was only
> sent to me and Andrew
On Thu, Oct 01, 2020 at 12:19:57PM -0700, Linus Torvalds wrote:
> Adding Vlastimil, Roman and the kernel mailing list to the cc.
>
> Vlastimil, Roman - this looks like a slab regression. And while others
> have touched slab in this merge window, you guys did so more than
> most.. Comments?
Thank
On Thu, Oct 01, 2020 at 07:00:36PM +0200, Michal Koutny wrote:
> Hi.
>
> On Wed, Sep 30, 2020 at 05:27:10PM -0700, Roman Gushchin wrote:
> > @@ -369,8 +371,12 @@ enum page_memcg_data_flags {
> > */
> > static inline struct mem_cgroup *page_memcg(struct page *page)
&
On Thu, Oct 01, 2020 at 09:46:38AM -0400, Johannes Weiner wrote:
> On Wed, Sep 30, 2020 at 05:27:07PM -0700, Roman Gushchin wrote:
> > +/*
> > + * set_page_memcg - associate a page with a memory cgroup
> > + * @page: a pointer to the page struct
> > + * @memcg: a p
verted to unsigned long memcg_data.
Only new helpers and a couple of slab-accounting related functions
access this field directly.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
---
fs/buffer.c | 2 +-
fs/iomap/buffered-io.c | 2 +-
include/linux/memcon
fixed a bug in page_obj_cgroups_check()
- moved some definitions between patches, by Shakeel
- dropped the memcg flags mutual exclusion requirement, by Shakeel
v1:
- added and fixed comments, by Shakeel
- added some VM_BUG_ON() checks
- fixed the debug output format of page->mem
, struct obj_cgroup **objcgs);
They are similar to the corresponding API for generic pages, except
that the setter can return false, indicating that the value has been
already set from a different thread.
Signed-off-by: Roman Gushchin
Acked-by: Johannes Weiner
---
include/linux/memcontrol.h
ght be added later.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 7e3da7cdc1ba..5e05599e1
MemcgKmem() and an open-coded OR operation setting the memcg
pointer with the MEMCG_DATA_KMEM bit. __ClearPageKmemcg() can be
simple deleted, as the whole memcg_data is zeroed at once.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
---
incl
On Wed, Sep 30, 2020 at 04:35:37PM -0700, Shakeel Butt wrote:
> On Tue, Sep 29, 2020 at 4:59 PM Roman Gushchin wrote:
> >
> > The lowest bit in page->memcg_data is used to distinguish between
> > struct memory_cgroup pointer and a pointer to a objcgs array.
> >
MemcgKmem() and __SetPageMemcgKmem(). __ClearPageKmemcg()
can be simple deleted because clear_page_mem_cgroup() already
does the job.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
---
include/linux/memcontr
y uses a direct access, struct page's
mem_cgroup/obj_cgroups is converted to unsigned long memcg_data.
Only new helpers and a couple of slab-accounting related functions
access this field directly.
Signed-off-by: Roman Gushchin
---
fs/buffer.c | 2 +-
fs/iomap/buffere
- moved some definitions between patches, by Shakeel
- dropped the memcg flags mutual exclusion requirement, by Shakeel
v1:
- added and fixed comments, by Shakeel
- added some VM_BUG_ON() checks
- fixed the debug output format of page->memcg_data
Roman Gushchin (4):
mm: memcontr
page *page, struct obj_cgroup **objcgs);
void clear_page_objcgs(struct page *page);
They are similar to the corresponding API for generic pages, except
that the setter can return false, indicating that the value has been
already set from a different thread.
Signed-off-by: Roman Gushchin
ght be added later.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index d4d15c04bbaf..35f846c6b89b 100644
--- a/include/li
> > static void drain_cpu_caches(struct kmem_cache *cachep)
> > @@ -3402,9 +3406,9 @@ static void cache_flusharray(struct kmem_cache
> > *cachep, struct array_cache *ac)
> > }
> > #endif
> > spin_unlock(>list_lock);
> > - slabs_destroy(cachep, );
> > ac->avail -= batchcount;
> > memmove(ac->entry, &(ac->entry[batchcount]), sizeof(void *)*ac->avail);
> > + slabs_destroy(cachep, );
> > }
>
> The issue can't be reproduced after applying this patch:
>
> Tested-by: Ming Lei
Perfect, thank you very much for the confirmation!
Shakeel, can you, please, resend the patch with the proper fixes tag
and the updated commit log? Please, feel free to add
Reviewed-by: Roman Gushchin .
Thank you!
Roman
On Fri, Sep 25, 2020 at 12:19:02PM -0700, Shakeel Butt wrote:
> On Fri, Sep 25, 2020 at 10:58 AM Shakeel Butt
> wrote:
> >
> [snip]
> >
> > I don't think you can ignore the flushing. The __free_once() in
> > ___cache_free() assumes there is a space available.
> >
> > BTW do_drain() also have the
On Fri, Sep 25, 2020 at 10:35:03AM -0700, Shakeel Butt wrote:
> On Fri, Sep 25, 2020 at 10:22 AM Shakeel Butt wrote:
> >
> > On Fri, Sep 25, 2020 at 10:17 AM Linus Torvalds
> > wrote:
> > >
> > > On Fri, Sep 25, 2020 at 9:19 AM Ming Lei wrote:
> > > >
> > > > git bisect shows the first bad
On Fri, Sep 25, 2020 at 09:47:43AM -0700, Shakeel Butt wrote:
> On Fri, Sep 25, 2020 at 9:32 AM Shakeel Butt wrote:
> >
> > On Fri, Sep 25, 2020 at 9:19 AM Ming Lei wrote:
> > >
> > > On Fri, Sep 25, 2020 at 03:31:45PM +0800, Ming Lei wrote:
> > > > On Thu, Sep 24, 2020 at 09:13:11PM -0400,
On Thu, Sep 24, 2020 at 04:14:17PM -0400, Johannes Weiner wrote:
> On Tue, Sep 22, 2020 at 01:37:00PM -0700, Roman Gushchin wrote:
> > PageKmemcg flag is currently defined as a page type (like buddy,
> > offline, table and guard). Semantically it means that the page
> > was
On Thu, Sep 24, 2020 at 04:01:22PM -0400, Johannes Weiner wrote:
> On Tue, Sep 22, 2020 at 01:36:59PM -0700, Roman Gushchin wrote:
> > The lowest bit in page->memcg_data is used to distinguish between
> > struct memory_cgroup pointer and a pointer to a objcgs arr
On Thu, Sep 24, 2020 at 03:53:56PM -0400, Johannes Weiner wrote:
> On Tue, Sep 22, 2020 at 01:36:58PM -0700, Roman Gushchin wrote:
> > To gather all direct accesses to struct page's memcg_data field
> > in one place, let's introduce 4 new helper functions to use in
> > the
On Thu, Sep 24, 2020 at 03:45:08PM -0400, Johannes Weiner wrote:
> On Tue, Sep 22, 2020 at 01:36:57PM -0700, Roman Gushchin wrote:
> > Currently there are many open-coded reads and writes of the
> > page->mem_cgroup pointer, as well as a couple of read helpers,
> &g
1:
- added and fixed comments, by Shakeel
- added some VM_BUG_ON() checks
- fixed the debug output format of page->memcg_data
Roman Gushchin (4):
mm: memcontrol: use helpers to access page's memcg data
mm: memcontrol/slab: use helpers to access slab page's memcg_data
mm: introduce p
ses with test_bit()/__set_bit().
Additional flags might be added later.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
in
-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 80 ++
mm/memcontrol.c| 4 +-
mm/slab.h | 27 ++---
3 files changed, 85 insertions(+), 26 deletions(-)
diff --git a/include/linux/memcontrol.h b/include
MemcgKmem() and SetPageMemcgKmem(). __ClearPageKmemcg()
can be simple deleted because clear_page_mem_cgroup() already
does the job.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontr
cg_rcu() has a single call site in a small rcu-read-lock
section, so it's just not worth it to have a separate helper. So
it's replaced with page_mem_cgroup() too.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
fs/buffer.c | 2 +-
fs/iomap/buffere
On Thu, Sep 24, 2020 at 12:03:35AM -0700, Shakeel Butt wrote:
> On Tue, Sep 22, 2020 at 1:38 PM Roman Gushchin wrote:
> >
> > The lowest bit in page->memcg_data is used to distinguish between
> > struct memory_cgroup pointer and a pointer to a objcgs array.
> >
and removes a couple of obsolete
functions. As the result the code became more robust with fewer
open-coded bits tricks.
v1:
- added and fixed comments, by Shakeel
- added some VM_BUG_ON() checks
- fixed the debug output format of page->memcg_data
Roman Gushchin (4):
mm: memcontr
ses with test_bit()/__set_bit().
Few additional flags might be added later. Flags are intended to be
mutually exclusive.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/include/li
cg_rcu() has a single call site in a small rcu-read-lock
section, so it's just not worth it to have a separate helper. So
it's replaced with page_mem_cgroup() too.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
fs/buffer.c | 2 +-
fs/iomap/buffere
-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 80 ++
mm/memcontrol.c| 4 +-
mm/slab.h | 27 ++---
3 files changed, 85 insertions(+), 26 deletions(-)
diff --git a/include/linux/memcontrol.h b/include
MemcgKmem() and SetPageMemcgKmem(). __ClearPageKmemcg()
can be simple deleted because clear_page_mem_cgroup() already
does the job.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
---
include/linux/memcontr
On Wed, Sep 16, 2020 at 06:12:37PM -0700, Shakeel Butt wrote:
> On Thu, Sep 10, 2020 at 1:27 PM Roman Gushchin wrote:
> >
> > To gather all direct accesses to struct page's memcg_data field
> > in one place, let's introduce 4 new helper functions to use in
> &g
On Fri, Sep 11, 2020 at 11:51:42AM +0800, Muchun Song wrote:
> On Fri, Sep 11, 2020 at 12:02 AM Shakeel Butt wrote:
> >
> > On Thu, Sep 10, 2020 at 1:46 AM Muchun Song
> > wrote:
> > >
> > > In the cgroup v1, we have a numa_stat interface. This is useful for
> > > providing visibility into the
On Fri, Sep 11, 2020 at 10:34:57AM -0700, Shakeel Butt wrote:
> On Fri, Sep 11, 2020 at 10:34 AM Shakeel Butt wrote:
> >
> > On Thu, Sep 10, 2020 at 1:27 PM Roman Gushchin wrote:
> > >
> > > Currently a non-slab kernel page which has been charged to a me
On Fri, Sep 11, 2020 at 09:21:49AM -0700, Shakeel Butt wrote:
> On Thu, Sep 10, 2020 at 3:43 PM Roman Gushchin wrote:
> >
> > Forgot to cc stable@, an updated version is below.
> >
> > Thanks!
> >
> > --
> >
> > From fe61af45ae570b143ca783b
Forgot to cc stable@, an updated version is below.
Thanks!
--
>From fe61af45ae570b143ca783ba4d013a0a2b923a15 Mon Sep 17 00:00:00 2001
From: Roman Gushchin
Date: Wed, 9 Sep 2020 12:19:37 -0700
Subject: [PATCH] mm: memcg/slab: fix racy access to page->mem_cgroup in
mem_cgroup_fr
cg_rcu() has a single call site in a small rcu-read-lock
section, so it's just not worth it to have a separate helper. So
it's replaced with page_mem_cgroup() too.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 72 +---
include/linux/mm.h
MemcgKmem() and SetPageMemcgKmem(). __ClearPageKmemcg()
can be simple deleted because clear_page_mem_cgroup() already
does the job.
As a bonus, on !CONFIG_MEMCG build the PageMemcgKmem() check will
be compiled out.
Signed-off-by: Roman Gushchin
---
include/linux/memcontr
ses with test_bit()/__set_bit().
Few additional flags might be added later. Flags are intended to be
mutually exclusive.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/include/li
a slab object
and page->mem_cgroup is NULL, it means that the object is not
accounted, so the function must return NULL.
I've discovered the race looking at the code, so far I haven't seen it
in the wild.
Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all
allocations&q
and removes a couple of obsolete
functions. As the result the code became more robust with fewer
open-coded bits tricks.
The first patch in the series is a bugfix, which I already sent separately.
Including it in rfc to make the whole series compile.
Roman Gushchin (5):
mm: memcg/slab: fix
-by: Roman Gushchin
---
include/linux/memcontrol.h | 48 ++
mm/memcontrol.c| 4 ++--
mm/slab.h | 27 +++--
3 files changed, 53 insertions(+), 26 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux
a slab object
and page->mem_cgroup is NULL, it means that the object is not
accounted, so the function must return NULL.
I've discovered the race looking at the code, so far I haven't seen it
in the wild.
Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all
allocations&q
On Wed, Sep 09, 2020 at 10:55:34AM -0400, Johannes Weiner wrote:
> On Thu, Sep 03, 2020 at 04:00:55PM -0700, Roman Gushchin wrote:
> > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > lists and the amount of slab memory (reclaimable and non-reclaimable)
&g
On Tue, Sep 08, 2020 at 11:09:25AM -0400, Zi Yan wrote:
> On 7 Sep 2020, at 3:20, Michal Hocko wrote:
>
> > On Fri 04-09-20 14:10:45, Roman Gushchin wrote:
> >> On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote:
> > [...]
> >>> An explicit op
ort comment here?
Something like "give oom_reaper a chance on a non-SMP system"?
> /*
>* keep retrying as long as the memcg oom killer is able to make
>* a forward progress or bypass the charge if the oom killer
> --
> 2.17.1
>
The patch makes total sense to me. Please, feel free to add
Acked-by: Roman Gushchin after adding a comment.
Thank you!
On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote:
> On Thu 03-09-20 09:25:27, Roman Gushchin wrote:
> > On Thu, Sep 03, 2020 at 09:32:54AM +0200, Michal Hocko wrote:
> > > On Wed 02-09-20 14:06:12, Zi Yan wrote:
> > > > From: Z
On Thu, Sep 03, 2020 at 09:10:59PM -0700, Andrew Morton wrote:
> On Thu, 3 Sep 2020 16:00:55 -0700 Roman Gushchin wrote:
>
> > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > lists and the amount of slab memory (reclaimable and non-reclaimable)
adow_nodes().
Signed-off-by: Roman Gushchin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Shakeel Butt
---
mm/workingset.c | 4
1 file changed, 4 deletions(-)
diff --git a/mm/workingset.c b/mm/workingset.c
index 92e66113a577..50d53f3699e4 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
is likely to grow. Instead of
> using a static array for cma areas, use a simple linked list. These
> areas are used before normal memory allocators, so use the memblock
> allocator.
>
> Signed-off-by: Mike Kravetz
Sounds like a good idea!
That 7 always confused me.
Acked-by: Roman G
On Thu, Sep 03, 2020 at 05:23:00PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2020 at 02:06:12PM -0400, Zi Yan wrote:
> > From: Zi Yan
> >
> > Hi all,
> >
> > This patchset adds support for 1GB THP on x86_64. It is on top of
> > v5.9-rc2-mmots-2020-08-25-21-13.
> >
> > 1GB THP is more
On Thu, Sep 03, 2020 at 09:32:54AM +0200, Michal Hocko wrote:
> On Wed 02-09-20 14:06:12, Zi Yan wrote:
> > From: Zi Yan
> >
> > Hi all,
> >
> > This patchset adds support for 1GB THP on x86_64. It is on top of
> > v5.9-rc2-mmots-2020-08-25-21-13.
> >
> > 1GB THP is more flexible for reducing
to get it depending on the current context.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/sched/mm.h | 13 +--
mm/memcontrol.c | 48
2 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/linux/sched/
There are checks for current->mm and current->active_memcg
in get_obj_cgroup_from_current(), but these checks are redundant:
memcg_kmem_bypass() called just above performs same checks.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
mm/memcontrol.c | 3 ---
1 file chan
of the
memory pressure and an inability to put the workload under the limit
will eventually trigger the OOM.
To use active_memcg() helper, memcg_kmem_bypass() is moved back
to memcontrol.c.
Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel Butt
---
include/linux/memcontrol.h | 12
mm
Currently memcg_kmem_bypass() is called before obtaining the current
memory/obj cgroup using get_mem/obj_cgroup_from_current(). Moving
memcg_kmem_bypass() into get_mem/obj_cgroup_from_current() reduces
the number of call sites and allows further code simplifications.
Signed-off-by: Roman Gushchin
for it. The bpf memory
accounting will likely be the first user of it: a typical
example is a bpf program parsing an incoming network packet,
which allocates an entry in hashmap map to store some information.
v1:
- fixed a typo, by Shakeel
rfc:
https://lkml.org/lkml/2020/8/27/1155
Roman Gushchin (4
On Thu, Aug 27, 2020 at 02:58:50PM -0700, Shakeel Butt wrote:
> On Thu, Aug 27, 2020 at 10:52 AM Roman Gushchin wrote:
> >
> > Remote memcg charging API uses current->active_memcg to store the
> > currently active memory cgroup, which overwrites the memory cgroup
&g
to get it depending on the current context.
Signed-off-by: Roman Gushchin
---
include/linux/sched/mm.h | 13 +--
mm/memcontrol.c | 48
2 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
There are checks for current->mm and current->active_memcg
in get_obj_cgroup_from_current(), but these checks are redundant:
memcg_kmem_bypass() called just above performs same checks.
Signed-off-by: Roman Gushchin
---
mm/memcontrol.c | 3 ---
1 file changed, 3 deletions(-)
diff --gi
of the
memory pressure and an inability to put the workload under the limit
will eventually trigger the OOM.
To use active_memcg() helper, memcg_kmem_bypass() is moved back
to memcontrol.c.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 12
mm/memcontrol.c| 13
for it. The bpf memory
accounting will likely be the first user of it: a typical
example is a bpf program parsing an incoming network packet,
which allocates an entry in hashmap map to store some information.
Roman Gushchin (4):
mm: kmem: move memcg_kmem_bypass() calls to
get_mem
Currently memcg_kmem_bypass() is called before obtaining the current
memory/obj cgroup using get_mem/obj_cgroup_from_current(). Moving
memcg_kmem_bypass() into get_mem/obj_cgroup_from_current() reduces
the number of call sites and allows further code simplifications.
Signed-off-by: Roman Gushchin
On Tue, Aug 25, 2020 at 04:27:09PM -0700, Shakeel Butt wrote:
> On Fri, Aug 21, 2020 at 8:01 AM Roman Gushchin wrote:
> >
> > This patch enables memcg-based memory accounting for memory allocated
> > by __bpf_map_area_alloc(), which is used by most map types for
501 - 600 of 2791 matches
Mail list logo
