On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
>
> Switch to per-object accounting of non-root slab objects.
>
> Charging is performed using obj_cgroup API in the pre_alloc hook.
> Obj_cgroup is charged with the size of the object and the size
> of metadata: as now it's the size of an
from the slab code.
>
> Signed-off-by: Roman Gushchin
> Reviewed-by: Vlastimil Babka
Reviewed-by: Shakeel Butt
On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
>
> This is v6 of the slab cgroup controller rework.
>
> The patchset moves the accounting from the page level to the object
> level. It allows to share slab pages between memory cgroups.
> This leads to a significant win in the slab
On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
>
> To convert memcg and lruvec slab counters to bytes there must be
> a way to change these counters without touching node counters.
> Factor out __mod_memcg_lruvec_state() out of __mod_lruvec_state().
>
> Signed-off-by: Roman Gushchin
>
On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
>
> To implement per-object slab memory accounting, we need to
> convert slab vmstat counters to bytes. Actually, out of
> 4 levels of counters: global, per-node, per-memcg and per-lruvec
> only two last levels will require byte-sized counters.
On Tue, Jun 16, 2020 at 7:50 PM Roman Gushchin wrote:
>
> On Tue, Jun 16, 2020 at 06:52:09PM -0700, Shakeel Butt wrote:
> > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> > >
> > > To convert memcg and lruvec slab counters to bytes there must be
> &
ad.
>
> The size of slab memory shouldn't exceed 4Gb on 32-bit machines,
> so it will fit into atomic_long_t we use for vmstats.
>
> Signed-off-by: Roman Gushchin
> Acked-by: Johannes Weiner
> Acked-by: Vlastimil Babka
Reviewed-by: Shakeel Butt
On Tue, Jun 16, 2020 at 7:41 PM Roman Gushchin wrote:
>
> On Tue, Jun 16, 2020 at 06:46:56PM -0700, Shakeel Butt wrote:
> > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> > >
[...]
> >
> > Have you performed any [perf] testing on SLAB with this
o_index()
> will be a simple wrapper taking a page pointer and passing
> page_address(page) into __obj_to_index().
>
> Signed-off-by: Roman Gushchin
> Reviewed-by: Vlastimil Babka
> Acked-by: Johannes Weiner
Reviewed-by: Shakeel Butt
n attempt to read
> byte value, because at the moment no one actually needs bytes.
>
> Thanks to Johannes Weiner for the idea of having the byte-sized API
> on top of the page-sized internal storage.
>
> Signed-off-by: Roman Gushchin
> Acked-by: Johannes Weiner
> Reviewed-by: Vlastimil Babka
Reviewed-by: Shakeel Butt
(s))) {
> + memcg_kmem_put_cache(cachep);
I think you forgot to put obj_cgroup_put(*objcgp) here again.
> + cachep = NULL;
> + }
> +
> + return cachep;
> +}
> +
After the above fix:
Reviewed-by: Shakeel Butt
Suggested-by: Johannes Weiner
> Signed-off-by: Roman Gushchin
> Reviewed-by: Vlastimil Babka
Reviewed-by: Shakeel Butt
.
This patch make alias count explicit and adds reference counting to the
root kmem_caches. The reference of a root kmem cache is elevated on
merge and while its memcg kmem_cache is in the process of creation or
deactivation.
Signed-off-by: Shakeel Butt
---
include/linux/slab.h | 2 +
include
On Mon, May 21, 2018 at 11:42 AM Andrew Morton
wrote:
> On Mon, 21 May 2018 10:41:16 -0700 Shakeel Butt
wrote:
> > The memcg kmem cache creation and deactivation (SLUB only) is
> > asynchronous. If a root kmem cache is destroyed whose memcg cache is in
> > th
kmem_cache is not destroyed
in the middle. As the reference of kmem_cache is elevated on sharing,
the 'shared_count' does not need any locking protection as at worst it
can be out-dated for a small window which is tolerable.
Signed-off-by: Shakeel Butt
---
Changelog since v1:
- Added more
Hi Tejun,
On Fri, Jan 25, 2019 at 10:28 AM Tejun Heo wrote:
>
> Hello, Michal.
>
> On Fri, Jan 25, 2019 at 06:37:13PM +0100, Michal Hocko wrote:
> > > What if a user wants to monitor any ooms in the subtree tho, which is
> > > a valid use case?
> >
> > How is that information useful without know
Hi Tejun,
On Mon, Jan 28, 2019 at 8:05 AM Tejun Heo wrote:
>
> Hello, Shakeel.
>
> On Mon, Jan 28, 2019 at 07:59:33AM -0800, Shakeel Butt wrote:
> > Why not make this configurable at the delegation boundary? As you
> > mentioned, there are jobs who want centralized workl
On Sun, Jan 13, 2019 at 10:34 AM Michal Hocko wrote:
>
> On Fri 11-01-19 14:54:32, Shakeel Butt wrote:
> > Hi Johannes,
> >
> > On Fri, Jan 11, 2019 at 12:59 PM Johannes Weiner wrote:
> > >
> > > Hi Shakeel,
> > >
> > >
On Mon, Jan 14, 2019 at 11:25 PM Michal Hocko wrote:
>
> On Mon 14-01-19 12:18:07, Shakeel Butt wrote:
> > On Sun, Jan 13, 2019 at 10:34 AM Michal Hocko wrote:
> > >
> > > On Fri 11-01-19 14:54:32, Shakeel Butt wrote:
> > > > Hi Johannes,
> > >
Hi Tejun,
On Wed, Jan 30, 2019 at 9:07 AM Tejun Heo wrote:
>
> Hello, Michal.
>
> On Wed, Jan 30, 2019 at 05:50:58PM +0100, Michal Hocko wrote:
> > > Yeah, cgroup.events and .stat files as some of the local stats would
> > > be useful too, so if we don't flip memory.events we'll end up with sth
On Wed, Jan 30, 2019 at 11:30 AM Johannes Weiner wrote:
>
> On Wed, Jan 30, 2019 at 02:27:12PM -0500, Johannes Weiner wrote:
> > On Wed, Jan 30, 2019 at 11:11:44AM -0800, Shakeel Butt wrote:
> > > Hi Tejun,
> > >
> > > On Wed, Jan 30, 2019 at 9:07 AM
On Wed, Jun 20, 2018 at 5:08 AM Andrey Ryabinin wrote:
>
>
>
> On 06/20/2018 12:33 AM, Shakeel Butt wrote:
> > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs
> > allocated per node for a kmem_cache. Thus, slabs_node() in
> > __kmem_cache_em
ail.gmail.com
Fixes: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()")
Signed-off-by: Shakeel Butt
Suggested-by: David Rientjes
Reported-by: Jason A . Donenfeld
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc:
Cc:
Cc:
---
On Wed, Jun 20, 2018 at 6:15 PM Christopher Lameter wrote:
>
> On Wed, 20 Jun 2018, Shakeel Butt wrote:
>
> > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs
> > allocated per node for a kmem_cache. Thus, slabs_node() in
> > __kmem_cache_e
On Thu, Jun 21, 2018 at 8:01 AM Michal Hocko wrote:
>
> On Thu 21-06-18 01:15:30, Cristopher Lameter wrote:
> > On Wed, 20 Jun 2018, Shakeel Butt wrote:
> >
> > > For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs
> > > allocated per nod
p://lkml.kernel.org/r/CAHmME9rtoPwxUSnktxzKso14iuVCWT7BE_-_8PAC=pgw1ij...@mail.gmail.com
>
> Fixes: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()")
> Cc: Shakeel Butt
> Cc: David Rientjes
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: Joonsoo K
On Tue, Jun 19, 2018 at 12:55 PM Roman Gushchin wrote:
>
> On Tue, Jun 19, 2018 at 12:51:15PM -0700, Shakeel Butt wrote:
> > On Tue, Jun 19, 2018 at 10:41 AM Roman Gushchin wrote:
> > >
> > > On Tue, Jun 19, 2018 at 12:27:41PM -0400, Johannes Weiner wrote:
> &g
On Fri, Jun 22, 2018 at 5:06 PM Roman Gushchin wrote:
>
> Introduce the mem_cgroup_put() helper, which helps to eliminate
> guarding memcg css release with "#ifdef CONFIG_MEMCG" in multiple
> places.
>
> Signed-off-by: Roman Gushchin
Reviewed-by: Shakeel But
be used for charging and for buffer_head, the memcg of
the page can be charged. For directed charging, the caller can use the
scope API memalloc_[un]use_memcg() to specify the memcg to charge for
all the __GFP_ACCOUNT allocations within the scope.
Shakeel Butt (2):
fs: fsnotify: account fsnotify
to the listener's memcg. Thus we save the memcg reference in the
fsnotify_group structure of the listener.
This patch has also moved the members of fsnotify_group to keep the size
same, at least for 64 bit build, even with additional member by filling
the holes.
Signed-off-by: Shakeel Butt
Cc: Michal
on the system. So, the right way to charge buffer_head is
to extract the memcg from the page for which buffer_heads are being
allocated and then use targeted memcg charging API.
Signed-off-by: Shakeel Butt
---
Changelog since v1:
- simple code cleanups
fs/buffer.c| 15
On Mon, Jun 25, 2018 at 10:49 PM Amir Goldstein wrote:
>
...
>
> The verb 'unuse' takes an argument memcg and 'uses' it - too weird.
> You can use 'override'/'revert' verbs like override_creds or just call
> memalloc_use_memcg(old_memcg) since there is no reference taken
> anyway in use_memcg and
On Tue, Jun 26, 2018 at 11:55 AM Johannes Weiner wrote:
>
> On Tue, Jun 26, 2018 at 11:00:53AM -0700, Shakeel Butt wrote:
> > On Mon, Jun 25, 2018 at 10:49 PM Amir Goldstein wrote:
> > >
> > ...
> > >
> > > The verb 'unuse' takes an argument memcg
On Tue, Jun 26, 2018 at 12:03 PM Johannes Weiner wrote:
>
> On Mon, Jun 25, 2018 at 04:06:58PM -0700, Shakeel Butt wrote:
> > @@ -140,8 +141,9 @@ struct fanotify_event_info *fanotify_alloc_event(struct
> > fsnotify_group *group,
> >
The size of kvm's shadow page tables corresponds to the size of the
guest virtual machines on the system. Large VMs can spend a significant
amount of memory as shadow page tables which can not be left as system
memory overhead. So, account shadow page tables to the kmemcg.
Signed-off-by: Shakeel
be used for charging and for buffer_head, the memcg of
the page can be charged. For directed charging, the caller can use the
scope API memalloc_[un]use_memcg() to specify the memcg to charge for
all the __GFP_ACCOUNT allocations within the scope.
Shakeel Butt (2):
fs: fsnotify: account fsnotify
on the system. So, the right way to charge buffer_head is
to extract the memcg from the page for which buffer_heads are being
allocated and then use targeted memcg charging API.
Signed-off-by: Shakeel Butt
Cc: Michal Hocko
Cc: Jan Kara
Cc: Amir Goldstein
Cc: Greg Thelen
Cc: Johannes Weiner
Cc
to the listener's memcg. Thus we save the memcg reference in the
fsnotify_group structure of the listener.
This patch has also moved the members of fsnotify_group to keep the size
same, at least for 64 bit build, even with additional member by filling
the holes.
Signed-off-by: Shakeel Butt
Cc: Michal Hocko
On Wed, Jun 27, 2018 at 2:51 PM Eric Dumazet wrote:
>
>
>
> On 06/27/2018 01:41 PM, Shakeel Butt wrote:
> > Currently the kernel accounts the memory for network traffic through
> > mem_cgroup_[un]charge_skmem() interface. However the memory accounted
> > only in
On Thu, Jun 28, 2018 at 12:03 PM Jan Kara wrote:
>
> On Wed 27-06-18 12:12:49, Shakeel Butt wrote:
> > A lot of memory can be consumed by the events generated for the huge or
> > unlimited queues if there is either no or slow listener. This can cause
> > system level memo
On Thu, May 24, 2018 at 4:43 AM, Michal Hocko wrote:
> From: Michal Hocko
>
> Although the api is documented in the source code Ted has pointed out
> that there is no mention in the core-api Documentation and there are
> people looking there to find answers how to use a specific API.
>
> Cc:
m counter is set and reached.
Signed-off-by: Shakeel Butt
---
mm/memcontrol.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ab5673dbfc4e..0a88f824c550 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1893,6
On Mon, Jun 18, 2018 at 7:51 PM Jason A. Donenfeld wrote:
>
> Hello Shakeel,
>
> It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has
> introduced a regression. I've bisected a failing test to this commit,
> and after staring at the my code for a long time, I'm unable to find a
>
On Mon, Jun 18, 2018 at 9:08 PM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:59 AM Shakeel Butt wrote:
> > Hi Jason, yes please do send me the test suite with the kernel config.
>
> $ git clone https://git.zx2c4.com/WireGuard
> $ cd WireGuard/src
> $ [[ $(gcc
on the system. So, the right way to charge buffer_head is
to extract the memcg from the page for which buffer_heads are being
allocated and then use targeted memcg charging API.
Signed-off-by: Shakeel Butt
Cc: Jan Kara
Cc: Greg Thelen
Cc: Michal Hocko
Cc: Johannes Weiner
Cc: Vladimir Davydov
Cc
interrupts. For now
due to lack of actual use-case, targeted memcg charging for such
allocations is not added. Though this might change in future.
Signed-off-by: Shakeel Butt
Cc: Michal Hocko
Cc: Jan Kara
Cc: Amir Goldstein
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc
for targeted memcg charging. So, all the
__GFP_ACCOUNT alloctions within the specified scope will be charged to
the given target memcg.
Shakeel Butt (3):
mm: memcg: remote memcg charging for kmem allocations
fs: fsnotify: account fsnotify metadata to kmemcg
fs, mm: account buffer_head to kmemcg
the allocations
to the listener's memcg. Thus we save the memcg reference in the
fsnotify_group structure of the listener.
This patch has also moved the members of fsnotify_group to keep the size
same, at least for 64 bit build, even with additional member by filling
the holes.
Signed-off-by: Shakeel
On Tue, Jun 19, 2018 at 12:20 AM Amir Goldstein wrote:
>
> On Tue, Jun 19, 2018 at 8:13 AM, Shakeel Butt wrote:
> > A lot of memory can be consumed by the events generated for the huge or
> > unlimited queues if there is either no or slow listener. This can cause
>
On Tue, Jun 19, 2018 at 6:05 AM Jason A. Donenfeld wrote:
>
> HI Dimitry,
>
> On Tue, Jun 19, 2018 at 6:55 AM Dmitry Vyukov wrote:
> > Your code frees all entries before freeing the cache, right? If you
> > add total_entries check before freeing the cache, it does not fire,
> > right?
>
> Yes,
On Tue, Jun 19, 2018 at 8:19 AM Jason A. Donenfeld wrote:
>
> On Tue, Jun 19, 2018 at 5:08 PM Shakeel Butt wrote:
> > > > Are you using SLAB or SLUB? We stress kernel pretty heavily, but with
> > > > SLAB, and I suspect Shakeel may also be using SLAB. So
On Tue, Jun 19, 2018 at 10:41 AM Roman Gushchin wrote:
>
> On Tue, Jun 19, 2018 at 12:27:41PM -0400, Johannes Weiner wrote:
> > On Mon, Jun 18, 2018 at 10:13:27PM -0700, Shakeel Butt wrote:
> > > The buffer_head can consume a significant amount of system memory and
>
that __kmem_cache_shutdown() and __kmem_cache_shrink() are
not affected by !CONFIG_SLUB_DEBUG as they call flush_all() to clear
per-cpu slabs.
Fixes: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()")
Signed-off-by: Shakeel Butt
Reported-by: Jason A . Donenfeld
Cc: Christoph L
On Tue, Jun 19, 2018 at 2:33 PM Shakeel Butt wrote:
>
> For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs
> allocated per node for a kmem_cache. Thus, slabs_node() in
> __kmem_cache_empty() will always return 0. So, in such situation, it is
> required to chec
ils. Please fold patch 1 and introduce API along with the
> users.
>
Thanks a lot for the review. Ack, I will do as you suggested in next version.
> On Mon, Jun 18, 2018 at 10:13:24PM -0700, Shakeel Butt wrote:
> > This patchset introduces memcg variant memory allocation functio
On Tue, Jun 19, 2018 at 9:22 AM Johannes Weiner wrote:
>
> On Mon, Jun 18, 2018 at 10:13:25PM -0700, Shakeel Butt wrote:
> > @@ -248,6 +248,30 @@ static inline void memalloc_noreclaim_restore(unsigned
> > int flags)
> > current->flags = (current->
On Tue, Jun 19, 2018 at 5:49 PM David Rientjes wrote:
>
> On Tue, 19 Jun 2018, Shakeel Butt wrote:
>
> > diff --git a/mm/slub.c b/mm/slub.c
> > index a3b8467c14af..731c02b371ae 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -3673,9 +3673,23 @@ static
The size of kvm's shadow page tables corresponds to the size of the
guest virtual machines on the system. Large VMs can spend a significant
amount of memory as shadow page tables which can not be left as system
memory overhead. So, account shadow page tables to the kmemcg.
Signed-off-by: Shakeel
On Fri, Jun 29, 2018 at 7:55 AM Michal Hocko wrote:
>
> On Fri 29-06-18 16:40:23, Paolo Bonzini wrote:
> > On 29/06/2018 16:30, Michal Hocko wrote:
> > > I am not familiar wtih kvm to judge but if we are going to account this
> > > memory we will probably want to let oom_badness know how much
Hi Andres, this is a small cleanup to the patch "fs: fsnotify: account
fsnotify metadata to kmemcg". Please squash.
Signed-off-by: Shakeel Butt
---
fs/notify/fanotify/fanotify.c| 2 +-
fs/notify/inotify/inotify_fsnotify.c | 2 +-
2 files changed, 2 insertions(+), 2 deletion
On Mon, Jul 2, 2018 at 2:54 PM Shakeel Butt wrote:
>
> Hi Andres, this is a small cleanup to the patch "fs: fsnotify: account
*Andrew*
> fsnotify metadata to kmemcg". Please squash.
>
> Signed-off-by: Shakeel Butt
> ---
> fs/notify/fanotify/fanotify.c
The patch "fs, mm: account buffer_head to kmemcg" missed to add
__GFP_ACCOUNT flag into the gfp mask for directed memcg charging. So,
adding it. Andrew, please squash this into the original patch.
Signed-off-by: Shakeel Butt
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+),
On Tue, Jul 3, 2018 at 8:27 AM Matthew Wilcox wrote:
>
> On Tue, Jul 03, 2018 at 06:09:05PM +0300, Kirill Tkhai wrote:
> > +++ b/mm/vmscan.c
> > @@ -169,6 +169,49 @@ unsigned long vm_total_pages;
> > static LIST_HEAD(shrinker_list);
> > static DECLARE_RWSEM(shrinker_rwsem);
> >
> > +#ifdef
On Tue, Jul 3, 2018 at 9:17 AM Kirill Tkhai wrote:
>
> Hi, Shakeel,
>
> On 03.07.2018 18:46, Shakeel Butt wrote:
> > On Tue, Jul 3, 2018 at 8:27 AM Matthew Wilcox wrote:
> >>
> >> On Tue, Jul 03, 2018 at 06:09:05PM +0300, Kirill Tkhai wrote:
> >&g
, I asked Roman to separate this change out
and thus can be merged independently.
Shakeel
> > Link: http://lkml.kernel.org/r/20180623000600.5818-2-g...@fb.com
> > Signed-off-by: Roman Gushchin
> > Reviewed-by: Shakeel Butt
> > Reviewed-by: Andrew Morton
> > Cc: Sh
On Sat, May 26, 2018 at 11:51 AM, Vladimir Davydov
wrote:
> On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote:
>> Based on several conditions the kernel can decide to force charge an
>> allocation for a memcg i.e. overcharge memcg->memory and memcg->memsw
>
On Sat, May 26, 2018 at 11:58 AM, Vladimir Davydov
wrote:
> On Tue, May 22, 2018 at 01:13:36PM -0700, Shakeel Butt wrote:
>> The memcg kmem cache creation and deactivation (SLUB only) is
>> asynchronous. If a root kmem cache is destroyed whose memcg cache is in
>> th
On Mon, May 28, 2018 at 2:11 AM, Michal Hocko wrote:
> On Sat 26-05-18 15:37:05, Shakeel Butt wrote:
>> On Sat, May 26, 2018 at 11:51 AM, Vladimir Davydov
>> wrote:
>> > On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote:
>> >> Based on several condi
On Mon, Apr 16, 2018 at 1:51 PM, Shakeel Butt wrote:
> Introduce the memcg variant for kmalloc[_node] and
> kmem_cache_alloc[_node]. For kmem_cache_alloc, the kernel switches the
> root kmem cache with the memcg specific kmem cache for __GFP_ACCOUNT
> allocations to charge those
On Wed, Jul 18, 2018 at 7:29 AM Bruce Merry wrote:
>
> On 18 July 2018 at 12:42, Michal Hocko wrote:
> > [CC some more people]
> >
> > On Tue 17-07-18 21:23:07, Andrew Morton wrote:
> >> (cc linux-mm)
> >>
> >> On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote:
> >>
> >> > Hi
> >> >
> >> >
On Wed, Jul 18, 2018 at 8:27 AM Bruce Merry wrote:
>
> On 18 July 2018 at 16:47, Michal Hocko wrote:
> >> Thanks for looking into this. I'm not familiar with ftrace. Can you
> >> give me a specific command line to run? Based on "perf record cat
> >> /sys/fs/cgroup/memory/memory.stat"/"perf
On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote:
>
> On 18 July 2018 at 17:26, Shakeel Butt wrote:
> > On Wed, Jul 18, 2018 at 7:29 AM Bruce Merry wrote:
> > It seems like you are using cgroup-v1. How many nodes are there in
> > your memcg tree and also how many c
On Wed, Jul 18, 2018 at 10:40 AM Bruce Merry wrote:
>
> On 18 July 2018 at 17:49, Shakeel Butt wrote:
> > On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote:
> >> That sounds promising. Is there any way to tell how many zombies there
> >> are, and is there any way
On Wed, Jul 18, 2018 at 10:58 AM Bruce Merry wrote:
>
> On 18 July 2018 at 19:48, Shakeel Butt wrote:
> > On Wed, Jul 18, 2018 at 10:40 AM Bruce Merry wrote:
> >> > Yes, very easy to produce zombies, though I don't think kernel
> >> > provides an
On Wed, Dec 12, 2018 at 7:51 AM Michal Hocko wrote:
>
> From: Michal Hocko
>
> Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the
> ext4 writeback
> task1:
> [] wait_on_page_bit+0x82/0xa0
> [] shrink_page_list+0x907/0x960
> [] shrink_inactive_list+0x2c7/0x680
> []
On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
>
> Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> ("mm: rework memcg kernel stack accounting") on a system with
> "cgroup_disable=memory" boot option: the system panics with the
> following stack trace:
>
>
On Mon, Oct 29, 2018 at 6:01 PM Rik van Riel wrote:
>
> On Mon, 2018-10-29 at 17:50 -0700, Shakeel Butt wrote:
> > On Mon, Oct 29, 2018 at 2:52 PM Roman Gushchin wrote:
> > >
> > > Mike Galbraith reported a regression caused by the commit
> > > 9b6f7e163cd
On Tue, Oct 30, 2018 at 8:56 AM Roman Gushchin wrote:
>
> On Tue, Oct 30, 2018 at 07:12:49AM +0100, Michal Hocko wrote:
> > On Mon 29-10-18 21:51:55, Roman Gushchin wrote:
> > > Mike Galbraith reported a regression caused by the commit 9b6f7e163cd0
> > > ("mm: rework memcg kernel stack
of_tasks), which can't be released even by significant
> memory pressure.
>
> As a cgroup structure can take a significant amount of memory
> (first of all, per-cpu data like memcg statistics), it leads
> to a noticeable waste of memory.
>
> Signed-off-by: Roman Gushchin
Reviewed
heap.
>
> Signed-off-by: Roman Gushchin
Seems reasonable.
Reviewed-by: Shakeel Butt
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Konstantin Khlebnikov
> Cc: Tejun Heo
> ---
> mm/memcontrol.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/me
also looking into this issue. I was thinking of having a
per-memcg per-cpu stack cache. However this solution seems much
simpler. Can you also add the performance number for a similar simple
benchmark done in ac496bf48d97 ("fork: Optimize task creation by
caching two thread stacks per CPU if
On Wed, Aug 15, 2018 at 10:26 AM Roman Gushchin wrote:
>
> On Wed, Aug 15, 2018 at 10:12:42AM -0700, Andy Lutomirski wrote:
> >
> >
> > > On Aug 15, 2018, at 9:55 AM, Roman Gushchin wrote:
> > >
> > >> On Wed, Aug 15, 2018 at 12:39:23PM -0400, Johannes Weiner wrote:
> > >>> On Tue, Aug 14, 2018
G" in multiple places.
> >
> > Link: http://lkml.kernel.org/r/20180623000600.5818-2-g...@fb.com
> > Signed-off-by: Roman Gushchin
> > Reviewed-by: Shakeel Butt
> > Reviewed-by: Andrew Morton
> > Acked-by: Johannes Weiner
> > Acked-by: Michal Hocko
On Thu, Aug 2, 2018 at 9:47 AM Yang Shi wrote:
>
> On Thu, Aug 2, 2018 at 4:00 AM, Kirill Tkhai wrote:
> > In case of shrink_slab_memcg() we do not zero nid, when shrinker
> > is not numa-aware. This is not a real problem, since currently
> > all memcg-aware shrinkers are numa-aware too (we have
On Wed, Aug 29, 2018 at 2:24 PM Roman Gushchin wrote:
>
> On Tue, Aug 21, 2018 at 03:10:52PM -0700, Shakeel Butt wrote:
> > On Tue, Aug 21, 2018 at 2:36 PM Roman Gushchin wrote:
> > >
> > > If CONFIG_VMAP_STACK is set, kernel stacks are allocated
&g
quot;
> > series, which is already in mm tree), all the evil in perf
> > trace has moved from shrink_slab() to down_read_trylock().
> > As reported by Shakeel Butt:
> >
> > > I created 255 memcgs, 255 ext4 mounts and made each memcg create a
>
On Wed, Aug 8, 2018 at 11:02 AM Josh Triplett wrote:
>
> On Wed, Aug 08, 2018 at 07:30:13PM +0300, Kirill Tkhai wrote:
> > On 08.08.2018 19:23, Kirill Tkhai wrote:
> > > On 08.08.2018 19:13, Josh Triplett wrote:
> > >> On Wed, Aug 08, 2018 at 01:17:44PM +0300, Kirill Tkhai wrote:
> > >>> On
sion in cache
> workingset transition")
> Signed-off-by: Johannes Weiner
Reviewed-by: Shakeel Butt
> ---
> mm/vmscan.c | 29 +
> 1 file changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 347c
On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
>
> This commit makes several important changes in the lifecycle
> of a non-root kmem_cache, which also affect the lifecycle
> of a memory cgroup.
>
> Currently each charged slab page has a page->mem_cgroup pointer
> to the memory cgroup and
On Wed, Apr 17, 2019 at 5:39 PM Roman Gushchin wrote:
>
> On Wed, Apr 17, 2019 at 04:41:01PM -0700, Shakeel Butt wrote:
> > On Wed, Apr 17, 2019 at 2:55 PM Roman Gushchin wrote:
> > >
> > > This commit makes several important changes in the lifecycle
> > &g
On Wed, Apr 17, 2019 at 8:07 PM Roman Gushchin wrote:
>
> On Wed, Apr 17, 2019 at 06:55:12PM -0700, Shakeel Butt wrote:
> > On Wed, Apr 17, 2019 at 5:39 PM Roman Gushchin wrote:
> > >
> > > On Wed, Apr 17, 2019 at 04:41:01PM -0700, Shakeel Butt wrote:
> >
not
cause zombie apocalypse.
Signed-off-by: Shakeel Butt
---
mm/memcontrol.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2535e54e7989..7b8de091f572 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -178,6 +178,7
Hi Roman,
On Tue, Apr 23, 2019 at 9:30 PM Roman Gushchin wrote:
>
> Currently the page accounting code is duplicated in SLAB and SLUB
> internals. Let's move it into new (un)charge_slab_page helpers
> in the slab_common.c file. These helpers will be responsible
> for statistics (global and
On Wed, Apr 24, 2019 at 12:17 PM Roman Gushchin wrote:
>
> On Wed, Apr 24, 2019 at 10:23:45AM -0700, Shakeel Butt wrote:
> > Hi Roman,
> >
> > On Tue, Apr 23, 2019 at 9:30 PM Roman Gushchin wrote:
> > >
> > > Currently the page accounting code is d
gt; > static inline struct list_lru_one *
>
> Yep, I didn't expect node 0 could ever be unavailable, my bad.
> The patch looks fine to me:
>
> Acked-by: Vladimir Davydov
>
> However, I tend to agree with Michal that (ab)using node[0].memcg_lrus
> to check if a list_lru is me
er
> Cc: Michal Hocko
> Cc: Mel Gorman
> Cc: "Kirill A . Shutemov"
> Cc: Hugh Dickins
> Signed-off-by: Yang Shi
Nice find.
Reviewed-by: Shakeel Butt
> ---
> I'm not quite sure if it was the intended behavior or just omission. I tried
> to dig into the review
From: Roman Gushchin
Date: Wed, May 8, 2019 at 1:30 PM
To: Andrew Morton, Shakeel Butt
Cc: , ,
, Johannes Weiner, Michal Hocko, Rik van Riel,
Christoph Lameter, Vladimir Davydov, , Roman
Gushchin
> Initialize kmem_cache->memcg_params.memcg pointer in
> memcg_link_cache() ra
From: Roman Gushchin
Date: Wed, May 8, 2019 at 1:30 PM
To: Andrew Morton, Shakeel Butt
Cc: , ,
, Johannes Weiner, Michal Hocko, Rik van Riel,
Christoph Lameter, Vladimir Davydov, , Roman
Gushchin
> # Why do we need this?
>
> We've noticed that the number of dying cgroups is steadil
From: Roman Gushchin
Date: Wed, May 8, 2019 at 1:30 PM
To: Andrew Morton, Shakeel Butt
Cc: , ,
, Johannes Weiner, Michal Hocko, Rik van Riel,
Christoph Lameter, Vladimir Davydov, , Roman
Gushchin
> Currently SLUB uses a work scheduled after an RCU grace period
> to deactivate a no
From: Roman Gushchin
Date: Wed, May 8, 2019 at 1:30 PM
To: Andrew Morton, Shakeel Butt
Cc: , ,
, Johannes Weiner, Michal Hocko, Rik van Riel,
Christoph Lameter, Vladimir Davydov, , Roman
Gushchin
> Let's separate the page counter modification code out of
> __memcg_kmem_uncharge() in
801 - 900 of 1184 matches
Mail list logo
