+linux-mm, linux-kernel
On Thu, Aug 17, 2017 at 6:10 PM, Shakeel Butt wrote:
> The fadvise() manpage is silent on fadvise()'s effect on
> memory-based filesystems (shmem, hugetlbfs & ramfs) and pseudo
> file systems (procfs, sysfs, kernfs). The current implementaion
> of fad
> +
> +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control
> *oc)
> +{
> + struct mem_cgroup *iter;
> +
> + oc->chosen_memcg = NULL;
> + oc->chosen_points = 0;
> +
> + /*
> +* The oom_score is calculated for leaf memory cgroups (including
> +
On Tue, Oct 31, 2017 at 9:40 AM, Johannes Weiner wrote:
> On Tue, Oct 31, 2017 at 08:04:19AM -0700, Shakeel Butt wrote:
>> > +
>> > +static void select_victim_memcg(struct mem_cgroup *root, struct
>> > oom_control *oc)
>> > +{
>> > +
unregistering shrinker likely returns shortly, and
> we can avoid khungtaskd warnings when do_shrink_slab() of unregistering
> shrinker unexpectedly took so long.
>
> Signed-off-by: Tetsuo Handa
Reviewed-and-tested-by: Shakeel Butt
> ---
>
On Tue, Nov 14, 2017 at 4:56 PM, Minchan Kim wrote:
> On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote:
>> When shrinker_rwsem was introduced, it was assumed that
>> register_shrinker()/unregister_shrinker() are really unlikely paths
>> which are called during initialization and tear d
. Without this patch, the
pages allocated for System V shared memory segment are added to
evictable LRUs even after shmctl(SHM_LOCK) on that segment. This
patch will correctly put such pages to unevictable LRU.
Signed-off-by: Shakeel Butt
---
include/linux/swap.h | 2 --
mm/swap.c| 68
(). Also there is no
need for local lru_add_drain() as it will be called deep inside
__mm_populate() (in follow_page_pte()).
Signed-off-by: Shakeel Butt
---
mm/mlock.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/mm/mlock.c b/mm/mlock.c
index dfc6f1912176..3ceb2935d1e0 100644
--- a/mm
On Thu, Oct 19, 2017 at 3:18 AM, Kirill A. Shutemov
wrote:
> On Wed, Oct 18, 2017 at 04:17:30PM -0700, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swa
On Thu, Oct 19, 2017 at 5:32 AM, Michal Hocko wrote:
> On Wed 18-10-17 16:17:30, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap and the latency
On Wed, Oct 18, 2017 at 11:24 PM, Anshuman Khandual
wrote:
> On 10/19/2017 04:47 AM, Shakeel Butt wrote:
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap and the latency
> [...]
>>
>> Sorry for the confusion. I wanted to say that if the pages which are
>> being mlocked are on caches of remote cpus then lru_add_drain_all will
>> move them to their corresponding LRUs and then remaining functionality
>> of mlock will move them again from their evictable LRUs to unevic
On Wed, Oct 18, 2017 at 8:18 PM, Balbir Singh wrote:
> On Wed, 18 Oct 2017 16:17:30 -0700
> Shakeel Butt wrote:
>
>> Recently we have observed high latency in mlock() in our generic
>> library and noticed that users have started using tmpfs files even
>> without swap
On Thu, Oct 19, 2017 at 1:13 PM, Michal Hocko wrote:
> On Thu 19-10-17 12:46:50, Shakeel Butt wrote:
>> > [...]
>> >>
>> >> Sorry for the confusion. I wanted to say that if the pages which are
>> >> being mlocked are on caches of remote cpus then
follow_page_pte()).
On larger machines the overhead of lru_add_drain_all() in mlock() can
be significant when mlocking data already in memory. We have observed
high latency in mlock() due to lru_add_drain_all() when the users
were mlocking in memory tmpfs files.
Signed-off-by: Shakeel Butt
---
Changelog
> Why is OOM-disabling a thing? Why isn't this simply a "kill everything
> else before you kill me"? It's crashing the kernel in trying to
> protect a userspace application. How is that not insane?
In parallel to other discussion, I think we should definitely move
from "completely oom-disabled" se
On Mon, Oct 30, 2017 at 1:29 AM, Michal Hocko wrote:
> On Fri 27-10-17 13:50:47, Shakeel Butt wrote:
>> > Why is OOM-disabling a thing? Why isn't this simply a "kill everything
>> > else before you kill me"? It's crashing the kernel in trying to
>>
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
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, 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_empty(
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_empty()
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 node for
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
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
> >
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 08.08.
mber_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
f-by: Kirill Tkhai
Reviewed-by: Shakeel Butt
> ---
> mm/vmscan.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 9918bfc1d2f9..636657213b9b 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -445,16
On Thu, Jul 19, 2018 at 3:43 AM Michal Hocko wrote:
>
> [CC Andrew]
>
> On Thu 19-07-18 18:06:47, Jing Xia wrote:
> > It was reported that a kernel crash happened in mem_cgroup_iter(),
> > which can be triggered if the legacy cgroup-v1 non-hierarchical
> > mode is used.
> >
> > Unable to handle ke
On Sun, Jun 17, 2018 at 2:57 PM Alexey Dobriyan wrote:
>
> commit 24074a35c5c975c94cd9691ae962855333aac47f
> ("proc: Make inline name size calculation automatic")
> started to put PDE allocations into kmalloc-256 which is unnecessary as
> ~40 character names are very rare.
>
> Put allocation back
, 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: Shake
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
&g
On Sun, Jul 22, 2018 at 11:44 PM Michal Hocko wrote:
>
> On Thu 19-07-18 09:23:10, Shakeel Butt wrote:
> > On Thu, Jul 19, 2018 at 3:43 AM Michal Hocko wrote:
> > >
> > > [CC Andrew]
> > >
> > > On Thu 19-07-18 18:06:47, Jing Xia wrote:
> &g
resense of 2500 memcgs on cgroup-v1. The results are:
Without the patch:
$ time ./read-root-stat-1000-times
real0m1.663s
user0m0.000s
sys 0m1.660s
With the patch:
$ time ./read-root-stat-1000-times
real0m0.468s
user0m0.000s
sys 0m0.467s
Signed-off-by: Shakeel Butt
---
On Wed, Jul 25, 2018 at 4:26 AM Bruce Merry wrote:
>
> On 25 July 2018 at 00:46, Shakeel Butt wrote:
> > I ran a simple benchmark which reads the root_mem_cgroup's stat file
> > 1000 times in the presense of 2500 memcgs on cgroup-v1. The results are:
> >
> > W
On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote:
>
> try_charge maybe executed in packet receive path, which is in interrupt
> context.
> In this situation, the 'current' is the interrupted task, which may has
> no relation to the rx softirq, So it is nonsense to use 'current'.
>
Have you actua
On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote:
>
> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote:
> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote:
> >>
> >> try_charge maybe executed in packet receive path, which is in interrupt
> >&g
On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao wrote:
>
> On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt wrote:
> > On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote:
> >>
> >> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote:
> >> > On Sat,
On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
>
> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
> > On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao wrote:
> >>
> >> On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt wrote:
> >> > On Sat,
On Sun, Jul 15, 2018 at 6:50 PM Yafang Shao wrote:
>
> On Sun, Jul 15, 2018 at 11:04 PM, Shakeel Butt wrote:
> > On Sun, Jul 15, 2018 at 1:02 AM Yafang Shao wrote:
> >>
> >> On Sun, Jul 15, 2018 at 2:34 PM, Shakeel Butt wrote:
> >> > On Sat, Jul 14, 2
On Wed, Jan 24, 2018 at 3:12 AM, Amir Goldstein wrote:
> On Wed, Jan 24, 2018 at 12:34 PM, Jan Kara wrote:
>> On Mon 22-01-18 22:31:20, Amir Goldstein wrote:
>>> On Fri, Jan 19, 2018 at 5:02 PM, Shakeel Butt wrote:
>>> > On Wed, Nov 15, 2017 at 1:31 AM, Jan Kara
On Wed, Jan 24, 2018 at 5:54 PM, Al Viro wrote:
> On Wed, Jan 24, 2018 at 05:08:27PM -0800, Shakeel Butt wrote:
>> First, let me apologize, I think I might have led the discussion in
>> wrong direction by giving one wrong information. The current upstream
>> kernel, from the
On Wed, Jan 24, 2018 at 11:51 PM, Amir Goldstein wrote:
>
> There is a nicer alternative, instead of failing the file access,
> an overflow event can be queued. I sent a patch for that and Jan
> agreed to the concept, but thought we should let user opt-in for this
> change:
> https://marc.info/?l=
On Fri, Jan 12, 2018 at 4:24 AM, Michal Hocko wrote:
> On Fri 12-01-18 00:59:38, Andrey Ryabinin wrote:
>> On 01/11/2018 07:29 PM, Michal Hocko wrote:
> [...]
>> > I do not think so. Consider that this reclaim races with other
>> > reclaimers. Now you are reclaiming a large chunk so you might end
ain why over-reclaim is a concern at
all? The only side effect of over reclaim I can think of is the job
might suffer a bit over (more swapins & pageins). Shouldn't this be
within the expectation of the user decreasing the limits?
> nack. If we ever see such a problem then reverting thi
On Wed, Nov 15, 2017 at 1:31 AM, Jan Kara wrote:
> On Wed 15-11-17 01:32:16, Yang Shi wrote:
>>
>>
>> On 11/14/17 1:39 AM, Michal Hocko wrote:
>> >On Tue 14-11-17 03:10:22, Yang Shi wrote:
>> >>
>> >>
>> >>On 11/9/17 5:54 AM, Michal Hocko wrote:
>> >>>[Sorry for the late reply]
>> >>>
>> >>>On Tue
On Fri, Jan 19, 2018 at 7:11 AM, Michal Hocko wrote:
> On Fri 19-01-18 06:49:29, Shakeel Butt wrote:
>> On Fri, Jan 19, 2018 at 5:35 AM, Michal Hocko wrote:
>> > On Fri 19-01-18 16:25:44, Andrey Ryabinin wrote:
>> >> Currently mem_cgroup_resize_limit() retries
On Tue, Jan 9, 2018 at 8:58 AM, Andrey Ryabinin wrote:
> mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost
> identical functions. Instead of having two of them, we could pass an
> additional argument to mem_cgroup_resize_limit() and by using it,
> consolidate all the code in
he reclaim doesn't make
> any progress or a signal is pending.
>
> Signed-off-by: Andrey Ryabinin
Reviewed-by: Shakeel Butt
On Mon, Jan 15, 2018 at 4:29 AM, Andrey Ryabinin
wrote:
>
>
> On 01/13/2018 01:57 AM, Shakeel Butt wrote:
>> On Fri, Jan 12, 2018 at 4:24 AM, Michal Hocko wrote:
>>> On Fri 12-01-18 00:59:38, Andrey Ryabinin wrote:
>>>> On 01/11/2018 07:29 PM, Michal Hocko w
target_memcg in task_struct in
v3 and in v4, added node variant for kmem allocation functions and
rebased fsnotify patch over Jan's patches.
Shakeel Butt (2):
mm: memcg: remote memcg charging for kmem allocations
fs: fsnotify: account fsnotify metadata to kmemcg
fs/notify/dnotify/dnot
instead of the producer.
One requirement to call these functions is that the caller must have the
reference to the memcg. Using kmalloc_memcg and kmem_cache_alloc_memcg
implicitly assumes that the caller is requesting a __GFP_ACCOUNT
allocation.
Signed-off-by: Shakeel Butt
---
Changelog since v3
e 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: Sh
gt; We had a check for PROT_READ/WRITE, but it did not work
> for PROT_NONE. This entirely removes the PROT_* checks,
> which ensures that PROT_NONE now works.
>
> Reported-by: Shakeel Butt
>
> Signed-off-by: Dave Hansen
Should there be a 'Fixes' tag? Also should this pa
On Fri, Mar 23, 2018 at 12:23 PM, Dave Hansen wrote:
> On 03/23/2018 12:15 PM, Shakeel Butt wrote:
>>> We had a check for PROT_READ/WRITE, but it did not work
>>> for PROT_NONE. This entirely removes the PROT_* checks,
>>> which ensures that PROT_NONE now works.
>
Wed, Mar 21, 2018 at 03:43:01PM -0700, Shakeel Butt wrote:
>> With kmem cgroup support, high memcgs churn can leave behind a lot of
>> empty kmem_caches. Usually such kmem_caches will be destroyed when the
>> corresponding memcg gets released but the memcg release can be
>>
have any effect on a systems with all workload
> concentrated in a single cgroup.
>
> Signed-off-by: Andrey Ryabinin
Seems reasonable.
Reviewed-by: Shakeel Butt
> ---
> mm/vmscan.c | 124
> +++-
> 1 file changed
On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin
wrote:
> memcg reclaim may alter pgdat->flags based on the state of LRU lists
> in cgroup and its children. PGDAT_WRITEBACK may force kswapd to sleep
> congested_wait(), PGDAT_DIRTY may force kswapd to writeback filesystem
> pages. But the worst her
On Fri, Apr 6, 2018 at 4:44 AM, Andrey Ryabinin wrote:
> On 04/06/2018 05:13 AM, Shakeel Butt wrote:
>> On Fri, Mar 23, 2018 at 8:20 AM, Andrey Ryabinin
>> wrote:
>>> memcg reclaim may alter pgdat->flags based on the state of LRU lists
>>> in cgroup and its
On Fri, Apr 6, 2018 at 6:52 AM, Andrey Ryabinin wrote:
> On 04/06/2018 05:13 AM, Shakeel Butt wrote:
>> Question: Should this 'flags' be per-node? Is it ok for a congested
>> memcg to call wait_iff_congested for all nodes?
>
> Indeed, congestion state should be
On Fri, Apr 6, 2018 at 8:09 AM, Andrey Ryabinin wrote:
>
>
> On 04/06/2018 05:37 PM, Shakeel Butt wrote:
>
>>>
>>> @@ -2482,7 +2494,7 @@ static inline bool should_continue_reclaim(struct
>>> pglist_data *pgdat,
>>> static bool pgdat_mem
fy. Maybe we can thing of something that would put the burden on
> the charging context?
What do you think of the following?
Signed-off-by: Shakeel Butt
---
mm/memcontrol.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/mm/me
d33e075c ("slab: implement slab_root_caches list")
Signed-off-by: Shakeel Butt
---
mm/slab.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/slab.c b/mm/slab.c
index 324446621b3e..9095c3945425 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1283,6 +1283,7 @@ void __
hould destroy such empty offlined kmem_caches.
Signed-off-by: Shakeel Butt
---
mm/slab.c| 18 --
mm/slab.h| 15 +++
mm/slab_common.c | 2 +-
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 66f2db9
an once a week.
>>
>> UML on i386 and/or x86_64:
>>
>> defconfig, CONFIG_MEMCG is not set:
>>
>> ../fs/notify/group.c: In function 'fsnotify_final_destroy_group':
>> ../fs/notify/group.c:41:24: error: dereferencing pointer to incomplete type
>&g
On Wed, Mar 7, 2018 at 6:34 PM, Shakeel Butt wrote:
> On Wed, Mar 7, 2018 at 6:23 PM, Randy Dunlap wrote:
>> On 03/07/2018 06:20 PM, Randy Dunlap wrote:
>>> On 03/07/2018 04:20 PM, a...@linux-foundation.org wrote:
>>>> The mm-of-the-moment snapshot 2018-03
This patch exports mem_cgroup_put API to put the refcnt of the memory
cgroup.
Signed-off-by: Shakeel Butt
---
include/linux/memcontrol.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index c46016bb25eb..0da79e116a07 100644
On Thu, Mar 8, 2018 at 3:45 PM, Andrew Morton wrote:
> On Wed, 7 Mar 2018 18:48:50 -0800 Shakeel Butt wrote:
>
>> This patch exports mem_cgroup_put API to put the refcnt of the memory
>> cgroup.
>
> OK, I remember now. This is intended to make
> fs-fsnotify-a
x27;s size. For SLUB, the non-root slab's
size is measured based on the root's object_size and thus the size will
remain same for root and non-root slab.
This patch makes slab's object_size the default base to measure the
slab's size.
Signed-off-by: Shakeel Butt
---
mm/s
On Tue, Mar 13, 2018 at 10:19 AM, Christopher Lameter wrote:
> On Tue, 13 Mar 2018, Shakeel Butt wrote:
>
>> However for SLUB in debug kernel, the sizes were same. On further
>> inspection it is found that SLUB always use kmem_cache.object_size to
>> measure the kmem_cache
On Tue, Mar 13, 2018 at 6:49 AM, Michal Hocko wrote:
> On Wed 21-02-18 14:37:56, Shakeel Butt wrote:
> [...]
>> +#ifdef CONFIG_MEMCG
>> +static inline struct mem_cgroup *memalloc_memcg_save(struct mem_cgroup
>> *memcg)
>> +{
>> + struct mem_cgrou
On Wed, Mar 14, 2018 at 1:43 AM, Vladimir Davydov
wrote:
> On Tue, Mar 13, 2018 at 10:36:52AM -0700, Shakeel Butt wrote:
>> On Tue, Mar 13, 2018 at 10:19 AM, Christopher Lameter wrote:
>> > On Tue, 13 Mar 2018, Shakeel Butt wrote:
>> >
>> >> However for SL
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: Sh
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 memo
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(+),
he consumer can 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: a
o 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
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 argu
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: Sh
he consumer can 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: a
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
o 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: Mi
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: "Dar
ounter 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 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
>> the p
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
> b
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
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
ons during 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: Joons
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
e 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-b
1 - 100 of 935 matches
Mail list logo
