On Tue, Apr 02, 2024 at 02:14:58PM +0800, Ubisectech Sirius wrote:
> > On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> >>> On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> >>> Hello.
> >>> We are Ubisectech Sirius Team, the vulnerability lab of China
On Tue, Apr 02, 2024 at 02:14:58PM +0800, Ubisectech Sirius wrote:
> > On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> >>> On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> >>> Hello.
> >>> We are Ubisectech Sirius Team, the vulnerability lab of China
On Tue, Apr 02, 2024 at 09:50:54AM +0800, Ubisectech Sirius wrote:
> > On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7.
On Mon, Apr 01, 2024 at 03:04:46PM +0800, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Thank you for the
from sidelined_slot -> to_depopulate_slot occurs on a
> threshold instead of before where it directly went to the
> to_depopulate_slot. pcpu_nr_isolated_empty_pop_pages[] is introduced to
> aid with this.
>
> Suggested-by: Roman Gushchin
> Signed-off-by: Dennis Zhou
Acked-by: Roman Gushchin
Thanks, Dennis!
On Mon, Apr 19, 2021 at 10:50:45PM +, Dennis Zhou wrote:
> This prepares for adding a to_depopulate list and sidelined list after
> the free slot in the set of lists in pcpu_slot.
>
> Signed-off-by: Dennis Zhou
Acked-by: Roman Gushchin
On Mon, Apr 19, 2021 at 06:44:02PM -0700, Shakeel Butt wrote:
> Proposal: Provide memory guarantees to userspace oom-killer.
>
> Background:
>
> Issues with kernel oom-killer:
> 1. Very conservative and prefer to reclaim. Applications can suffer
> for a long time.
> 2. Borrows the context of the
On Sat, Apr 17, 2021 at 01:14:03AM +0530, Pratik Sampat wrote:
>
>
> On 17/04/21 12:39 am, Roman Gushchin wrote:
> > On Sat, Apr 17, 2021 at 12:11:37AM +0530, Pratik Sampat wrote:
> > >
> > > On 17/04/21 12:04 am, Roman Gushchin wrote:
> > > > On
On Sat, Apr 17, 2021 at 12:11:37AM +0530, Pratik Sampat wrote:
>
>
> On 17/04/21 12:04 am, Roman Gushchin wrote:
> > On Fri, Apr 16, 2021 at 11:57:03PM +0530, Pratik Sampat wrote:
> > >
> > > On 16/04/21 10:43 pm, Roman Gushchin wrote:
> > > > On
On Fri, Apr 16, 2021 at 11:57:03PM +0530, Pratik Sampat wrote:
>
>
> On 16/04/21 10:43 pm, Roman Gushchin wrote:
> > On Fri, Apr 16, 2021 at 08:58:33PM +0530, Pratik Sampat wrote:
> > > Hello Dennis,
> > >
> > > I apologize for the clutter of logs bef
, so can you, please, make
sure that the data is correct and we're not messing two cases?
So it looks like for some reason sidelined (depopulated) chunks are not getting
freed completely. But I struggle to explain why the initial empty_pop_pages is
bigger with the same amount of chunks.
So, can you,
e shouldn't be. Can you send me the percpu_stats debug output before
> and after?
Btw, sidelined chunks are not listed in the debug output. It was actually on my
to-do list, looks like I need to prioritize it a bit.
>
> > I will also look through the code to find the reason why POWER is
p_disabled() and
> CONFIG_MEMCG.
>
> Signed-off-by: Muchun Song
> Acked-by: Johannes Weiner
Acked-by: Roman Gushchin
> ---
> include/linux/memcontrol.h | 31 +++
> 1 file changed, 7 insertions(+), 24 deletions(-)
>
> diff --git a/inclu
On Tue, Apr 13, 2021 at 02:51:52PM +0800, Muchun Song wrote:
> The css_set_lock is used to guard the list of inherited objcgs. So there
> is no need to uncharge kernel memory under css_set_lock. Just move it
> out of the lock.
>
> Signed-off-by: Muchun Song
Acked-by:
It is also
> impossible for the two to run in parallel. So xchg() is unnecessary
> and it is enough to use WRITE_ONCE().
>
> Signed-off-by: Muchun Song
> Acked-by: Johannes Weiner
It's a good one! It took me some time to realize that it's safe.
Thanks!
Acked
to the local variable of @pgdat. So mem_cgroup_page_lruvec() do not
> need the pgdat parameter. Just remove it to simplify the code.
>
> Signed-off-by: Muchun Song
> Acked-by: Johannes Weiner
Acked-by: Roman Gushchin
> ---
> include/linux/memcontrol.h | 10 +-
> mm/comp
Acked-by: Johannes Weiner
> Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Nice!
> ---
> mm/memcontrol.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index f229de925aa5..9cbf
l problem, but
> there is a WARN_ON_ONCE in the page_counter_cancel(). Who knows if it
> will trigger? So it is better to fix it.
>
> Signed-off-by: Muchun Song
> Acked-by: Johannes Weiner
> Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Thanks!
> ---
> mm/memcontrol.c | 8 +---
>
On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
> With the recent introduction of the new slab memory controller, we
> eliminate the need for having separate kmemcaches for each memory
> cgroup and reduce overall kernel memory usage. However, we also add
> additional memory accounting
extra memory space is not a significant concern.
I'd be more worried about the code complexity, but the result looks
nice to me!
Acked-by: Roman Gushchin
Btw, it seems that the mm tree ran a bit off, so I had to apply this series
on top of Linus's tree to review. Please, rebase.
Thanks!
an Long
Acked-by: Roman Gushchin
On Fri, Apr 09, 2021 at 07:18:40PM -0400, Waiman Long wrote:
> Before the new slab memory controller with per object byte charging,
> charging and vmstat data update happen only when new slab pages are
> allocated or freed. Now they are done with every kmem_cache_alloc()
> and kmem_cache_free().
inefficient. Introduce a new function obj_cgroup_uncharge_mod_state()
> that combines them with a single irq_save/irq_restore cycle.
>
> Signed-off-by: Waiman Long
Acked-by: Roman Gushchin
Thanks!
ease,
add a couple of words about it? E.g. we need it to handle stats which do not
exist on the lruvec level...
Otherwise,
Acked-by: Roman Gushchin
Thanks!
>
> Signed-off-by: Waiman Long
> ---
> include/linux/memcontrol.h | 12 +++-
> mm/memcontrol.c| 19
On Mon, Apr 12, 2021 at 10:03:13AM -0400, Waiman Long wrote:
> On 4/9/21 9:51 PM, Roman Gushchin wrote:
> > On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
> > > With the recent introduction of the new slab memory controller, we
> > > eliminate the need for
On Mon, Apr 12, 2021 at 01:14:57PM -0400, Johannes Weiner wrote:
> On Fri, Apr 09, 2021 at 06:29:46PM -0700, Roman Gushchin wrote:
> > On Fri, Apr 09, 2021 at 08:29:41PM +0800, Muchun Song wrote:
> > > Since the following patchsets applied. All the kernel memory are charged
>
On Fri, Apr 09, 2021 at 07:18:37PM -0400, Waiman Long wrote:
> With the recent introduction of the new slab memory controller, we
> eliminate the need for having separate kmemcaches for each memory
> cgroup and reduce overall kernel memory usage. However, we also add
> additional memory accounting
On Fri, Apr 09, 2021 at 08:29:41PM +0800, Muchun Song wrote:
> Since the following patchsets applied. All the kernel memory are charged
> with the new APIs of obj_cgroup.
>
> [v17,00/19] The new cgroup slab memory controller
> [v5,0/7] Use obj_cgroup APIs to charge kmem pages
>
> But
> save stack memory. But the commit 2bcf88796381 ("mm: take pagevecs off
> reclaim stack") replace pagevecs by lists of pages_to_free. So we do
> not need noinline_for_stack, just remove it (let the compiler decide
> whether to inline).
>
> Signed-off-by: Muchun Song
Acke
eat ideas and a very constructive
discussion which led to many improvements in this patchset!
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 2 +
mm/percpu.c | 158 ++-
2 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/mm/per
ted is introduced, chunk->depopulate is dropped
- rearranged patches a bit
- fixed a panic discovered by krobot
- made pcpu_nr_empty_pop_pages per chunk type
- minor fixes
rfc:
https://lwn.net/Articles/850508/
Roman Gushchin (6):
percpu: fix a comment about the chunks ordering
p
.
Otherwise an infinite loop might appear.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 63 +
1 file changed, 39 insertions(+), 24 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 61339b3d9337..e20119668c42 100644
--- a/mm/percpu.c
+++ b/mm
logic
per chunk type.
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 2 +-
mm/percpu-stats.c| 9 +++--
mm/percpu.c | 14 +++---
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/mm/percpu-internal.h b/mm/percpu-internal.h
index 18b768ac7dca
Factor out the pcpu_check_chunk_hint() helper, which will be useful
in the future. The new function checks if the allocation can likely
fit the given chunk.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff
functionality, split it in two functions:
1) pcpu_balance_free,
2) pcpu_balance_populated.
Move the taking/releasing of the pcpu_alloc_mutex to an upper level
to keep the current synchronization in place.
Signed-off-by: Roman Gushchin
Reviewed-by: Dennis Zhou
---
mm/percpu.c | 46
Since the commit 3e54097beb22 ("percpu: manage chunks based on
contig_bits instead of free_bytes") chunks are sorted based on the
size of the biggest continuous free area instead of the total number
of free bytes. Update the corresponding comment to reflect this.
Signed-off-by: Roma
eat ideas and a very constructive
discussion which led to many improvements in this patchset!
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 2 +
mm/percpu.c | 164 ++-
2 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/mm/per
.
Otherwise an infinite loop might appear.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 63 +
1 file changed, 39 insertions(+), 24 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 61339b3d9337..e20119668c42 100644
--- a/mm/percpu.c
+++ b/mm
Since the commit 3e54097beb22 ("percpu: manage chunks based on
contig_bits instead of free_bytes") chunks are sorted based on the
size of the biggest continuous free area instead of the total number
of free bytes. Update the corresponding comment to reflect this.
Signed-off-by: Roma
logic
per chunk type.
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 2 +-
mm/percpu-stats.c| 9 +++--
mm/percpu.c | 14 +++---
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/mm/percpu-internal.h b/mm/percpu-internal.h
index 18b768ac7dca
empty_pop_pages per chunk type
- minor fixes
rfc:
https://lwn.net/Articles/850508/
Roman Gushchin (5):
percpu: fix a comment about the chunks ordering
percpu: split __pcpu_balance_workfn()
percpu: make pcpu_nr_empty_pop_pages per chunk type
percpu: generalize pcpu_balance_populate
functionality, split it in two functions:
1) pcpu_balance_free,
2) pcpu_balance_populated.
Move the taking/releasing of the pcpu_alloc_mutex to an upper level
to keep the current synchronization in place.
Signed-off-by: Roman Gushchin
Reviewed-by: Dennis Zhou
---
mm/percpu.c | 46
mplementation.
>
> Signed-off-by: Mike Kravetz
Acked-by: Roman Gushchin
> ---
> mm/cma.c | 18 +-
> mm/cma.h | 2 +-
> mm/cma_debug.c | 8
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
&
On Mon, Apr 05, 2021 at 11:08:26AM -0700, Yang Shi wrote:
> On Sun, Apr 4, 2021 at 10:49 PM Bharata B Rao wrote:
> >
> > Hi,
> >
> > When running 1 (more-or-less-empty-)containers on a bare-metal Power9
> > server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
> > consumption
On Fri, Apr 02, 2021 at 06:04:54PM -0700, Andrew Morton wrote:
> On Wed, 31 Mar 2021 20:35:02 -0700 Roman Gushchin wrote:
>
> > On Thu, Apr 01, 2021 at 11:31:16AM +0800, Miaohe Lin wrote:
> > > On 2021/4/1 11:01, Muchun Song wrote:
> > > > Christian Borntraeger
.
Otherwise an infinite loop might appear.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 63 +
1 file changed, 39 insertions(+), 24 deletions(-)
diff --git a/mm/percpu.c b/mm/percpu.c
index 0eeeb4e7a2f9..25a181328353 100644
--- a/mm/percpu.c
+++ b/mm
uctive
discussion which led to many improvements in this patchset!
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 1 +
mm/percpu.c | 101 ++-
2 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/mm/percpu-internal.h b/mm/
Since the commit 3e54097beb22 ("percpu: manage chunks based on
contig_bits instead of free_bytes") chunks are sorted based on the
size of the biggest continuous free area instead of the total number
of free bytes. Update the corresponding comment to reflect this.
Signed-off-by: Roma
logic
per chunk type.
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 2 +-
mm/percpu-stats.c| 9 +++--
mm/percpu.c | 14 +++---
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/mm/percpu-internal.h b/mm/percpu-internal.h
index 18b768ac7dca
functionality, split it in two functions:
1) pcpu_balance_free,
2) pcpu_balance_populated.
Move the taking/releasing of the pcpu_alloc_mutex to an upper level
to keep the current synchronization in place.
Signed-off-by: Roman Gushchin
Reviewed-by: Dennis Zhou
---
mm/percpu.c | 46
- fixed a panic discovered by krobot
- made pcpu_nr_empty_pop_pages per chunk type
- minor fixes
rfc:
https://lwn.net/Articles/850508/
Roman Gushchin (5):
percpu: split __pcpu_balance_workfn()
percpu: make pcpu_nr_empty_pop_pages per chunk type
percpu: generalize pcpu_balance_po
On Fri, Apr 02, 2021 at 12:07:42AM +0800, Muchun Song wrote:
> On Wed, Mar 31, 2021 at 11:17 PM Johannes Weiner wrote:
> >
> > On Tue, Mar 30, 2021 at 03:05:42PM -0700, Roman Gushchin wrote:
> > > On Tue, Mar 30, 2021 at 05:30:10PM -0400, Johannes Weiner wrote:
> >
ee yet.
So the fix can be simply squashed.
Btw, the fix looks good to me.
Acked-by: Roman Gushchin
>
> > ---
> > include/linux/memcontrol.h | 6 ++
> > mm/memcontrol.c| 6 +-
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> >
On Tue, Mar 30, 2021 at 05:30:10PM -0400, Johannes Weiner wrote:
> On Tue, Mar 30, 2021 at 11:58:31AM -0700, Roman Gushchin wrote:
> > On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote:
> > > On Tue, Mar 30, 2021 at 3:20 AM Muchun Song
> > > wrote:
> >
On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote:
> On Tue, Mar 30, 2021 at 3:20 AM Muchun Song wrote:
> >
> > Since the following patchsets applied. All the kernel memory are charged
> > with the new APIs of obj_cgroup.
> >
> > [v17,00/19] The new cgroup slab memory
Kravetz
Acked-by: Roman Gushchin
Thanks!
> ---
> mm/cma.c | 20 +++-
> mm/cma.h | 2 +-
> mm/cma_debug.c | 10 ++
> 3 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index b2393b892d3b..80875fd4
destroy_compound_gigantic_page(page, huge_page_order(h));
> free_gigantic_page(page, huge_page_order(h));
> - spin_lock(_lock);
> } else {
> __free_pages(page, huge_page_order(h));
> }
> --
> 2.30.2
>
Acked-by: Roman Gushchin
Thanks!
On Mon, Mar 29, 2021 at 11:12:34PM +, Dennis Zhou wrote:
> On Mon, Mar 29, 2021 at 01:10:10PM -0700, Roman Gushchin wrote:
> > On Mon, Mar 29, 2021 at 07:21:24PM +, Dennis Zhou wrote:
> > > On Wed, Mar 24, 2021 at 12:06:25PM -0700, Roman Gushchin wrote:
> > >
On Mon, Mar 29, 2021 at 07:21:24PM +, Dennis Zhou wrote:
> On Wed, Mar 24, 2021 at 12:06:25PM -0700, Roman Gushchin wrote:
> > To return unused memory to the system schedule an async
> > depopulation of percpu chunks.
> >
> > To balance between scanning too mu
On Mon, Mar 29, 2021 at 07:28:49PM +, Dennis Zhou wrote:
> On Mon, Mar 29, 2021 at 11:29:22AM -0700, Roman Gushchin wrote:
> > On Mon, Mar 29, 2021 at 05:20:55PM +, Dennis Zhou wrote:
> > > On Wed, Mar 24, 2021 at 12:06:23PM -0700, Roman Gushchin wrote:
> > &
On Mon, Mar 29, 2021 at 05:20:55PM +, Dennis Zhou wrote:
> On Wed, Mar 24, 2021 at 12:06:23PM -0700, Roman Gushchin wrote:
> > This patch implements partial depopulation of percpu chunks.
> >
> > As now, a chunk can be depopulated only as a part of the final
On Mon, Mar 29, 2021 at 05:28:23PM +, Dennis Zhou wrote:
> On Wed, Mar 24, 2021 at 12:06:24PM -0700, Roman Gushchin wrote:
> > __pcpu_balance_workfn() became fairly big and hard to follow, but in
> > fact it consists of two fully independent parts, responsible for
>
t; url:
> https://github.com/0day-ci/linux/commits/Roman-Gushchin/percpu-partial-chunk-depopulation/20210325-030746
> base: https://git.kernel.org/cgit/linux/kernel/git/dennis/percpu.git for-next
>
> in testcase: trinity
> version: trinity-i386-4d2343bd-1_20200320
> with fol
56:38, David Hildenbrand wrote:
> > > > > On 25.03.21 01:28, Mike Kravetz wrote:
> > > > > > From: Roman Gushchin
> > > > > >
> > > > > > cma_release() has to lock the cma_lock mutex to clear the cma
> > > > > > bitmap.
> >
functionality, split it in two functions:
1) pcpu_balance_free,
2) pcpu_balance_populated.
Move the taking/releasing of the pcpu_alloc_mutex to an upper level
to keep the current synchronization in place.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 46
Since the commit 3e54097beb22 ("percpu: manage chunks based on
contig_bits instead of free_bytes") chunks are sorted based on the
size of the biggest continuous free area instead of the total number
of free bytes. Update the corresponding comment to reflect this.
Signed-off-by: Roma
153920 kB
So the total size of the percpu memory was reduced by ~3 times.
Roman Gushchin (4):
percpu: implement partial chunk depopulation
percpu: split __pcpu_balance_workfn()
percpu: on demand chunk depopulation
percpu: fix a comment about the c
to isolate it again on each step. pcpu_alloc_mutex is held, so the
chunk can't be populated/depopulated asynchronously.
Signed-off-by: Roman Gushchin
---
mm/percpu.c | 90 +
1 file changed, 90 insertions(+)
diff --git a/mm/percpu.c b/mm/percpu.c
the shrinking part of
pcpu_balance_populated() into pcpu_grow_populated() and make
pcpu_balance_populated() calling into pcpu_grow_populated() or
pcpu_shrink_populated() conditionally.
Signed-off-by: Roman Gushchin
---
mm/percpu-internal.h | 1 +
mm/percpu.c | 111
On Tue, Mar 23, 2021 at 11:51:04AM -0700, Mike Kravetz wrote:
> On 3/22/21 11:10 AM, Roman Gushchin wrote:
> > On Mon, Mar 22, 2021 at 10:42:23AM -0700, Mike Kravetz wrote:
> >> Cc: Roman, Christoph
> >>
> >> On 3/22/21 1:41 AM, Peter Zijlstra wrote:
> >&
25a74 ("mm: memcg/slab: optimize objcg stock draining")
> Signed-off-by: Muchun Song
Acked-by: Roman Gushchin
Thanks!
nd
> call obj_cgroup_uncharge_pages() in obj_cgroup_release().
>
> This is just code cleanup without any functionality changes.
>
> Signed-off-by: Muchun Song
Acked-by: Roman Gushchin
_objcg() to get the object
> cgroup associated with a kmem page. Or we can use page_memcg()
> to get the memory cgroup associated with a kmem page, but caller must
> ensure that the returned memcg won't be released (e.g. acquire the
> rcu_read_lock or css_set_lock).
>
> Signed-of
On Mon, Mar 22, 2021 at 10:42:23AM -0700, Mike Kravetz wrote:
> Cc: Roman, Christoph
>
> On 3/22/21 1:41 AM, Peter Zijlstra wrote:
> > On Fri, Mar 19, 2021 at 03:42:08PM -0700, Mike Kravetz wrote:
> >> The locks acquired in free_huge_page are irq safe. However, in certain
> >> circumstances the
On Mon, Mar 15, 2021 at 07:49:57PM +0100, Vlastimil Babka wrote:
> On 3/9/21 4:25 PM, Xunlei Pang wrote:
> > count_partial() can hold n->list_lock spinlock for quite long, which
> > makes much trouble to the system. This series eliminate this problem.
>
> Before I check the details, I have two
On Tue, Mar 09, 2021 at 06:07:15PM +0800, Muchun Song wrote:
> We want to reuse the obj_cgroup APIs to charge the kmem pages.
> If we do that, we should store an object cgroup pointer to
> page->memcg_data for the kmem pages.
>
> Finally, page->memcg_data can have 3 different meanings.
>
> 1)
On Tue, Mar 09, 2021 at 06:07:16PM +0800, Muchun Song wrote:
> Since Roman series "The new cgroup slab memory controller" applied. All
> slab objects are charged via the new APIs of obj_cgroup. The new APIs
> introduce a struct obj_cgroup to charge slab objects. It prevents
> long-living objects
;
> Signed-off-by: Muchun Song
Nice!
Acked-by: Roman Gushchin
Thanks!
> ---
> include/linux/memcontrol.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 07c449af9c0f..d3ca8
On Sun, Mar 07, 2021 at 10:13:04PM -0800, Shakeel Butt wrote:
> On Tue, Feb 16, 2021 at 4:13 PM Yang Shi wrote:
> >
> > Using kvfree_rcu() to free the old shrinker_maps instead of call_rcu().
> > We don't have to define a dedicated callback for call_rcu() anymore.
> >
> > Signed-off-by: Yang Shi
s without ebase register and
>to addtional reserve_exception_space for BMIPS CPUs
>
> arch/mips/include/asm/traps.h| 3 +++
> arch/mips/kernel/cpu-probe.c | 7 +++
> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
> arch/mips/kernel/traps.c | 10 +
charge_swapin_page(),
> adds the page to the swapcache and on success completes the charging
> process with mem_cgroup_finish_swapin_page().
>
> Signed-off-by: Shakeel Butt
> Acked-by: Johannes Weiner
> Acked-by: Hugh Dickins
Acked-by: Roman Gushchin
Thanks!
> ---
> Changes si
On Wed, Mar 03, 2021 at 01:59:16PM +0800, Muchun Song wrote:
> The remote memcg charing APIs is a mechanism to charge pages to a given
> memcg. Since all kernel memory are charged by using obj_cgroup APIs.
> Actually, we want to charge kernel memory to the remote object cgroup
> instead of memory
On Wed, Mar 03, 2021 at 01:59:15PM +0800, Muchun Song wrote:
> Since Roman series "The new cgroup slab memory controller" applied. All
> slab objects are charged via the new APIs of obj_cgroup. The new APIs
> introduce a struct obj_cgroup to charge slab objects. It prevents
> long-living objects
On Wed, Mar 03, 2021 at 01:59:14PM +0800, Muchun Song wrote:
> We want to reuse the obj_cgroup APIs to charge the kmem pages when
> If we do that, we should store an object cgroup pointer to
> page->memcg_data for the kmem pages.
>
> Finally, page->memcg_data can have 3 different meanings.
>
>
use _page suffix usually means
we're dealing with a physical page (e.g. struct page * as an argument),
here it's not the case.
Please, add my Acked-by: Roman Gushchin
after the renaming.
Thank you!
> ---
> mm/memcontrol.c | 46 +++---
> 1
and decrementation are decided by page migratetype, but the migratetype
> of a pageblock is not guaranteed to be constant.
>
> Roman Gushchin points out:
> For performance reasons, vmstat counters are incremented and decremented
> using per-cpu batches. vmstat_refresh() flushes the pe
vmalloc backing page to its own
> node.
>
> Signed-off-by: Muchun Song
> Reviewed-by: Shakeel Butt
> Acked-by: Michal Hocko
> Acked-by: Johannes Weiner
Acked-by: Roman Gushchin
Thanks!
> ---
> Changelog in v3:
> - Remove BUG_ON().
> - Update commit l
On Tue, Mar 02, 2021 at 08:33:20PM +0100, Michal Hocko wrote:
> On Tue 02-03-21 10:50:32, Roman Gushchin wrote:
> > On Tue, Mar 02, 2021 at 03:37:33PM +0800, Muchun Song wrote:
> > > The alloc_thread_stack_node() cannot guarantee that allocated stack pages
> > >
("memblock: do not start bottom-up allocations
> with kernel_end")
> Debugged-by: Serge Semin
> Reported-by: Kamal Dasu
> Signed-off-by: Florian Fainelli
Acked-by: Roman Gushchin
Thank you!
> ---
> Thomas,
>
> This is intended as a stop-gap solution for
On Tue, Mar 02, 2021 at 04:18:23PM +0800, Muchun Song wrote:
> CPU0: CPU1:
>
> objcg = get_obj_cgroup_from_current();
> obj_cgroup_charge(objcg);
> memcg_reparent_objcgs();
>
On Tue, Mar 02, 2021 at 03:37:33PM +0800, Muchun Song wrote:
> The alloc_thread_stack_node() cannot guarantee that allocated stack pages
> are in the same node when CONFIG_VMAP_STACK. Because we do not specify
> __GFP_THISNODE to __vmalloc_node_range(). Fix it by caling
> mod_lruvec_page_state()
On Mon, Mar 01, 2021 at 07:43:27PM -0800, Shakeel Butt wrote:
> On Mon, Mar 1, 2021 at 5:16 PM Roman Gushchin wrote:
> >
> > On Mon, Mar 01, 2021 at 02:22:26PM +0800, Muchun Song wrote:
> > > The remote memcg charing APIs is a mechanism to charge kernel memory
> >
On Mon, Mar 01, 2021 at 11:45:42AM +0200, Mike Rapoport wrote:
> On Sun, Feb 28, 2021 at 07:50:45PM -0800, Florian Fainelli wrote:
> > Hi Serge,
> >
> > On 2/28/2021 3:08 PM, Serge Semin wrote:
> > > Hi folks,
> > > What you've got here seems a more complicated problem than it
> > > could
On Mon, Mar 01, 2021 at 02:22:27PM +0800, Muchun Song wrote:
> We spent a lot of energy to make slab accounting do not hold a refcount
> to memory cgroup, so the dying cgroup can be freed as soon as possible
> on cgroup offlined.
>
> But some users of remote memory cgroup charging (e.g. bpf and
On Mon, Mar 01, 2021 at 02:22:26PM +0800, Muchun Song wrote:
> The remote memcg charing APIs is a mechanism to charge kernel memory
> to a given memcg. So we can move the infrastructure to the scope of
> the CONFIG_MEMCG_KMEM.
This is not a good idea, because there is nothing kmem-specific
in the
Hi Muchun!
On Mon, Mar 01, 2021 at 02:22:22PM +0800, Muchun Song wrote:
> Since Roman series "The new cgroup slab memory controller" applied. All
> slab objects are changed via the new APIs of obj_cgroup. This new APIs
> introduce a struct obj_cgroup instead of using struct mem_cgroup directly
>
Mon, Mar 01, 2021 at 02:08:17PM -0800, Hugh Dickins wrote:
> On Sun, 28 Feb 2021, Roman Gushchin wrote:
> > On Thu, Feb 25, 2021 at 03:14:03PM -0800, Hugh Dickins wrote:
> > > vmstat_refresh() can occasionally catch nr_zone_write_pending and
> > > nr_writeback when th
ed-off-by: Hugh Dickins
Acked-by: Roman Gushchin
Thanks!
> ---
>
> mm/vmstat.c |9 -
> 1 file changed, 9 deletions(-)
>
> --- vmstat3/mm/vmstat.c 2021-02-25 12:42:15.0 -0800
> +++ vmstat4/mm/vmstat.c 2021-02-25 12:44:20.0 -0800
> @@
on a reasonable sized machine.
Does it makes sense?
>
> Link: https://lore.kernel.org/linux-mm/20200714173747.3315771-1-g...@fb.com/
> Reported-by: Roman Gushchin
> Signed-off-by: Hugh Dickins
> ---
>
> mm/vmstat.c | 15 +++
> 1 file changed, 15 insertion
> tests much later to fail, just because their /proc/sys/vm/stat_refresh
> touch failed with that error. Stop doing that.
Totally agree!
>
> Signed-off-by: Hugh Dickins
Acked-by: Roman Gushchin
> ---
>
> mm/vmstat.c |5 -
> 1 file changed, 5 deletions(-)
&g
1 - 100 of 2788 matches
Mail list logo
