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
r-node vmstats")
> split NR_VM_NODE_STAT_ITEMS out of NR_VM_ZONE_STAT_ITEMS without updating
> vmstat_refresh(): so it has been missing out much of the vmstat underflow
> checking ever since. Reinstate it. Thanks to Roman Gushchin
> for tangentially pointing this out.
>
>
On Thu, Feb 25, 2021 at 09:21:04AM -0800, Hugh Dickins wrote:
> On Wed, 24 Feb 2021, Roman Gushchin wrote:
> > On Tue, Feb 23, 2021 at 11:24:23PM -0800, Hugh Dickins wrote:
> > > On Thu, 6 Aug 2020, Andrew Morton wrote:
> > > > On Thu, 6 Aug 2020 16:38:
On Tue, Feb 23, 2021 at 11:24:23PM -0800, Hugh Dickins wrote:
> On Thu, 6 Aug 2020, Andrew Morton wrote:
> > On Thu, 6 Aug 2020 16:38:04 -0700 Roman Gushchin wrote:
>
> August, yikes, I thought it was much more recent.
>
> >
> > > it seems that Hugh and me
ot;
> which is from memory.stat. Fix it by using mod_lruvec_page_state instead
> of mod_node_page_state.
>
> Fixes: 6a486c0ad4dc ("mm, sl[ou]b: improve memory accounting")
> Signed-off-by: Muchun Song
Reviewed-by: Roman Gushchin
Thanks!
- memcg = current->active_memcg;
> - }
> + /* remote memcg must hold a ref. */
> + if (memcg && WARN_ON_ONCE(!css_tryget(>css)))
> + memcg = root_mem_cgroup;
Ouch, this is a good one!
Reviewed-by: Roman Gushchin
Thank you!
by boot parameter
>
> Signed-off-by: Yang Shi
LGTM!
Acked-by: Roman Gushchin
Thanks!
ware shrinkers would solve the
> unfairness and bring
> better isolation.
>
> When memcg is not enabled (!CONFIG_MEMCG or memcg disabled), the shrinker's
> nr_deferred
> would be used. And non memcg aware shrinkers use shrinker's nr_deferred all
> the time
t; Acked-by: Vlastimil Babka
> Signed-off-by: Yang Shi
Acked-by: Roman Gushchin
> ---
> include/linux/shrinker.h | 7 ---
> mm/vmscan.c | 40 +++-
> 2 files changed, 19 insertions(+), 28 deletions(-)
>
> diff --gi
On Tue, Feb 16, 2021 at 04:13:14PM -0800, 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
Acked-by: Roman Gushchin
Thanks!
> ---
>
On Thu, Feb 04, 2021 at 01:19:47PM +0800, Xing Zhengjun wrote:
>
>
> On 2/3/2021 10:49 AM, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 04:18:27PM +0800, Xing, Zhengjun wrote:
> > > On 1/14/2021 11:18 AM, Roman Gushchin wrote:
> > > > On Thu, Jan 14, 2
On Tue, Feb 09, 2021 at 05:25:16PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 5:10 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> > > Currently the number of deferred objects are per shrinker, but some
> > > sl
On Tue, Feb 09, 2021 at 05:12:51PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 4:39 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:41AM -0800, Yang Shi wrote:
> > > Currently registered shrinker is indicated by non-NULL
> > > shrinker->nr_d
On Tue, Feb 09, 2021 at 05:07:07PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 4:22 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:40AM -0800, Yang Shi wrote:
> > > The shrinker_info is dereferenced in a couple of places via
> &g
On Tue, Feb 09, 2021 at 09:46:43AM -0800, Yang Shi wrote:
> Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
> nr_deferred
> will be used in the following cases:
> 1. Non memcg aware shrinkers
> 2. !CONFIG_MEMCG
> 3. memcg is disabled by boot parameter
>
>
FIG_MEMCG or memcg
> is disabled
> by kernel command line, then shrinker's SHRINKER_MEMCG_AWARE flag would be
> cleared.
> This makes the implementation of this patch simpler.
>
> Acked-by: Vlastimil Babka
> Reviewed-by: Kirill Tkhai
> Signed-off-by: Yang Shi
Acked
On Tue, Feb 09, 2021 at 09:46:45AM -0800, Yang Shi wrote:
> Now shrinker's nr_deferred is per memcg for memcg aware shrinkers, add to
> parent's
> corresponding nr_deferred when memcg offline.
>
> Acked-by: Vlastimil Babka
> Acked-by: Kirill Tkhai
> Signed-off-by: Yang
On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> Currently the number of deferred objects are per shrinker, but some slabs,
> for example,
> vfs inode/dentry cache are per memcg, this would result in poor isolation
> among memcgs.
>
> The deferred objects typically are generated by
On Tue, Feb 09, 2021 at 09:46:41AM -0800, Yang Shi wrote:
> Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred.
> This approach is fine with nr_deferred at the shrinker level, but the
> following
> patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so
> + lockdep_is_held(_rwsem));
> +}
> +
I'd probably drop the "protected" suffix (because there is no unprotected
version,
right?).
Other than that LGTM.
Acked-by: Roman Gushchin
On Tue, Feb 09, 2021 at 03:33:56PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 12:50 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:39AM -0800, Yang Shi wrote:
> > > The following patch is going to add nr_deferred into shrinker_map, the
>
y: Kirill Tkhai
> Signed-off-by: Yang Shi
Acked-by: Roman Gushchin
> ---
> mm/vmscan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b1b574ad199d..b512dd5e3a1c 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmsc
is being stored in a memcg structure. So
> move the
> shrinker_maps handling code into vmscan.c for tighter integration with
> shrinker code,
> and remove the "memcg_" prefix. There is no functional change.
>
> Acked-by: Vlastimil Babka
> Acked-by: Kirill Tkhai
> S
types of memory to the memory.stat side of the
> equation, since they're included in memory.current and could throw
> false positives.
>
> Signed-off-by: Johannes Weiner
> Reviewed-by: Shakeel Butt
Acked-by: Roman Gushchin
Thanks!
_one_shrinker_map(struct mem_cgroup
> *memcg,
> memset(new->map, (int)0xff, old_size);
> memset((void *)new->map + old_size, 0, size - old_size);
>
> - rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, new);
> - call_rcu(>rcu, free_shrinker_map_rcu);
> + rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, new);
> + call_rcu(>rcu, free_shrinker_info_rcu);
Why not use kvfree_rcu() and get rid of free_shrinker_info_rcu() callback?
Aside from this minor thing, the patch looks good to me. Please, feel free to
add
Acked-by: Roman Gushchin
Thanks!
On Tue, Feb 09, 2021 at 09:46:38AM -0800, Yang Shi wrote:
> Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but actually
> the
> map size can be calculated via shrinker_nr_max, so it seems unnecessary to
> keep both.
> Remove memcg_shrinker_map_size since shrinker_nr_max is also
gt; just one is being collected, but the rest of the flushing code is the
> same. Merge them into one function and share the common code.
>
> Signed-off-by: Johannes Weiner
> Reviewed-by: Shakeel Butt
> Acked-by: Michal Hocko
Acked-by: Roman Gushchin
Thanks!
;mem_cgroup_online() protects us from it? Yes, sure,
> but this is not the thing we want to remember in the future, since this
> spreads modularity.
>
> And a test with heavy paging workload didn't show write lock makes things
> worse.
>
> Acked-by: Vlastimil Babka
> A
ted-by: Muchun Song
> Signed-off-by: Johannes Weiner
Acked-by: Roman Gushchin
Thanks!
On Thu, Feb 04, 2021 at 01:19:47PM +0800, Xing Zhengjun wrote:
>
>
> On 2/3/2021 10:49 AM, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 04:18:27PM +0800, Xing, Zhengjun wrote:
> > > On 1/14/2021 11:18 AM, Roman Gushchin wrote:
> > > > On Thu, Jan 14, 2
On Thu, Feb 04, 2021 at 04:44:27PM -0500, Johannes Weiner wrote:
> On Tue, Feb 02, 2021 at 06:25:30PM -0800, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 01:47:46PM -0500, Johannes Weiner wrote:
> > > There are two functions to flush the per-cpu data of an lruvec i
On Thu, Feb 04, 2021 at 02:29:57PM -0500, Johannes Weiner wrote:
> On Tue, Feb 02, 2021 at 06:28:53PM -0800, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 03:07:47PM -0800, Roman Gushchin wrote:
> > > On Tue, Feb 02, 2021 at 01:47:40PM -0500, Johannes Weiner wrote:
> >
On Thu, Feb 04, 2021 at 11:26:32AM -0500, Johannes Weiner wrote:
> On Tue, Feb 02, 2021 at 05:47:26PM -0800, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 01:47:45PM -0500, Johannes Weiner wrote:
> > > for_each_node(node) {
> > > struct mem_cgroup_per
.c | 35 ---
> 1 file changed, 8 insertions(+), 27 deletions(-)
Nice cleanup!
Acked-by: Roman Gushchin
Thanks.
On Tue, Feb 02, 2021 at 04:18:27PM +0800, Xing, Zhengjun wrote:
>
>
> On 1/14/2021 11:18 AM, Roman Gushchin wrote:
> > On Thu, Jan 14, 2021 at 10:51:51AM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -62.4% regression of
On Tue, Feb 02, 2021 at 03:07:47PM -0800, Roman Gushchin wrote:
> On Tue, Feb 02, 2021 at 01:47:40PM -0500, Johannes Weiner wrote:
> > The memcg hotunplug callback erroneously flushes counts on the local
> > CPU, not the counts of the CPU going away; those counts will be lost.
emcg_online_kmem(struct mem_cgroup *memcg)
> {
> @@ -5197,7 +5193,7 @@ static void mem_cgroup_free(struct mem_cgroup *memcg)
>* Flush percpu lruvec stats to guarantee the value
>* correctness on parent's and all ancestor levels.
>*/
> - memcg_flush_lruvec_page_state(memcg);
> + memcg_flush_lruvec_page_state(memcg, -1);
I wonder if adding "cpu" or "percpu" into the function name will make clearer
what -1 means?
E.g. memcg_flush_(per)cpu_lruvec_stats(memcg, -1).
Reviewed-by: Roman Gushchin
* below us. We're in a per-cpu loop here and this is
> + * a global counter, so the first cycle will get them.
> + */
> + delta = memcg->vmstats.state_pending[i];
> + if (delta)
> + memcg->vmstats.state_pending[i] = 0;
> +
> + /* Add CPU changes on this level since the last flush */
> + v = READ_ONCE(statc->state[i]);
> + if (v != statc->state_prev[i]) {
> + delta += v - statc->state_prev[i];
> + statc->state_prev[i] = v;
> + }
> +
> + if (!delta)
> + continue;
> +
> + /* Aggregate counts on this level and propagate upwards */
> + memcg->vmstats.state[i] += delta;
> + if (parent)
> + parent->vmstats.state_pending[i] += delta;
> + }
> +
> + for (i = 0; i < NR_VM_EVENT_ITEMS; i++) {
> + delta = memcg->vmstats.events_pending[i];
> + if (delta)
> + memcg->vmstats.events_pending[i] = 0;
> +
> + v = READ_ONCE(statc->events[i]);
> + if (v != statc->events_prev[i]) {
> + delta += v - statc->events_prev[i];
> + statc->events_prev[i] = v;
> + }
> +
> + if (!delta)
> + continue;
> +
> + memcg->vmstats.events[i] += delta;
> + if (parent)
> + parent->vmstats.events_pending[i] += delta;
> + }
> +}
> +
> #ifdef CONFIG_MMU
> /* Handlers for move charge at task migration. */
> static int mem_cgroup_do_precharge(unsigned long count)
> @@ -6571,6 +6532,7 @@ struct cgroup_subsys memory_cgrp_subsys = {
> .css_released = mem_cgroup_css_released,
> .css_free = mem_cgroup_css_free,
> .css_reset = mem_cgroup_css_reset,
> + .css_rstat_flush = mem_cgroup_css_rstat_flush,
> .can_attach = mem_cgroup_can_attach,
> .cancel_attach = mem_cgroup_cancel_attach,
> .post_attach = mem_cgroup_move_task,
> --
> 2.30.0
>
With a tiny nit above
Reviewed-by: Roman Gushchin .
Thanks!
mount, the css moves back to the default hierarchy. Annotate
> rebind_subsystems() to move the root css linkage along between roots.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Roman Gushchin
On Tue, Feb 02, 2021 at 01:47:42PM -0500, Johannes Weiner wrote:
> There are no users outside of the memory controller itself. The rest
> of the kernel cares either about node or lruvec stats.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Roman Gushchin
On Tue, Feb 02, 2021 at 01:47:41PM -0500, Johannes Weiner wrote:
> No need to encapsulate a simple struct member access.
>
> Signed-off-by: Johannes Weiner
Reviewed-by: Roman Gushchin
are 32 CPUs and
1000 sub-cgroups (which is an absolutely realistic number, because
often there are many dying generations of each cgroup), the error
margin is 3.9GB. It makes all numbers pretty much random and all
possible tests extremely flaky.
>
> Signed-off-by: Johannes Weiner
To this patch
On Tue, Jan 26, 2021 at 04:05:55PM +0100, Michal Hocko wrote:
> On Tue 26-01-21 14:48:38, Matthew Wilcox wrote:
> > On Mon, Jan 25, 2021 at 11:38:17PM +0200, Mike Rapoport wrote:
> > > I cannot use __GFP_ACCOUNT because cma_alloc() does not use gfp.
> > > Besides, kmem accounting with
r-memcg kmem caches
> anymore.
>
> Signed-off-by: Vlastimil Babka
Nice cleanup!
Acked-by: Roman Gushchin
Thanks, Vlastimil!
> ---
> Documentation/admin-guide/kernel-parameters.txt | 8
> init/Kconfig
revert it again.
>
> Fixes: 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering
> memory.high")
> Cc: # 5.8+
> Reported-by: Tejun Heo
> Signed-off-by: Johannes Weiner
Acked-by: Roman Gushchin
On Thu, Jan 21, 2021 at 06:21:54PM +0100, Vlastimil Babka wrote:
> For performance reasons, SLUB doesn't keep all slabs on shared lists and
> doesn't always free slabs immediately after all objects are freed. Namely:
>
> - for each cache and cpu, there might be a "CPU slab" page, partially or
gt; > > > On Wed, Jan 13, 2021 at 10:43 AM Roman Gushchin wrote:
> > > > >
> > > > > On Tue, Jan 12, 2021 at 04:18:44PM -0800, Shakeel Butt wrote:
> > > > > > On Tue, Jan 12, 2021 at 4:12 PM Arjun Roy
> >
On Fri, Jan 15, 2021 at 03:55:36PM -0500, Johannes Weiner wrote:
> On Fri, Jan 15, 2021 at 09:03:41AM -0800, Roman Gushchin wrote:
> > On Fri, Jan 15, 2021 at 11:20:50AM -0500, Johannes Weiner wrote:
> > > On Wed, Jan 13, 2021 at 03:46:54PM +0100, Michal Hocko wrote:
> > &
On Fri, Jan 15, 2021 at 11:20:50AM -0500, Johannes Weiner wrote:
> On Wed, Jan 13, 2021 at 03:46:54PM +0100, Michal Hocko wrote:
> > On Tue 12-01-21 11:30:11, Johannes Weiner wrote:
> > > When a value is written to a cgroup's memory.high control file, the
> > > write() context first tries to
On Thu, Jan 14, 2021 at 10:51:51AM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -62.4% regression of hackbench.throughput due to commit:
Hi!
Commit "mm: memcg/slab: optimize objcg stock draining" (currently only in the
mm tree,
so no stable hash) should improve the
On Tue, Jan 12, 2021 at 09:27:51PM +0800, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 755e5d55367af5ff75a4db9b6cf439416878e2c7 ("bpf: Eliminate
> rlimit-based memory accounting for hashtab maps")
>
On Tue, Jan 12, 2021 at 04:12:08PM -0800, Arjun Roy wrote:
> On Tue, Jan 12, 2021 at 3:48 PM Roman Gushchin wrote:
> >
> > On Tue, Jan 12, 2021 at 03:36:18PM -0800, Arjun Roy wrote:
> > > On Tue, Jan 12, 2021 at 3:31 PM Roman Gushchin wrote:
> > > >
> &
On Tue, Jan 12, 2021 at 04:18:44PM -0800, Shakeel Butt wrote:
> On Tue, Jan 12, 2021 at 4:12 PM Arjun Roy wrote:
> >
> > On Tue, Jan 12, 2021 at 3:48 PM Roman Gushchin wrote:
> > >
> [snip]
> > > Historically we have a corresponding vmstat counter
_pages(memcg, nr_pages - high,
> - GFP_KERNEL, true);
> + try_to_free_mem_cgroup_pages(memcg, nr_pages - high,
> + GFP_KERNEL, true);
>
> - if (!reclaimed && !nr_retries--)
> + if (!nr_retries--)
> break;
> }
>
> --
> 2.30.0
>
Acked-by: Roman Gushchin
Thanks!
On Tue, Jan 12, 2021 at 03:36:18PM -0800, Arjun Roy wrote:
> On Tue, Jan 12, 2021 at 3:31 PM Roman Gushchin wrote:
> >
> > On Tue, Jan 12, 2021 at 01:41:05PM -0800, Shakeel Butt wrote:
> > > From: Arjun Roy
> > >
> > > TCP zerocopy receive is use
On Tue, Jan 12, 2021 at 01:41:05PM -0800, Shakeel Butt wrote:
> From: Arjun Roy
>
> TCP zerocopy receive is used by high performance network applications to
> further scale. For RX zerocopy, the memory containing the network data
> filled by network driver is directly mapped into the address
On Tue, Jan 12, 2021 at 02:45:43PM -0500, Johannes Weiner wrote:
> On Tue, Jan 12, 2021 at 09:03:22AM -0800, Roman Gushchin wrote:
> > On Tue, Jan 12, 2021 at 11:30:11AM -0500, Johannes Weiner wrote:
> > > When a value is written to a cgroup's memory.high control file, the
>
On Tue, Jan 12, 2021 at 04:11:27PM -0500, Johannes Weiner wrote:
> On Tue, Jan 12, 2021 at 12:12:37PM -0800, Roman Gushchin wrote:
> > On Tue, Jan 12, 2021 at 02:45:43PM -0500, Johannes Weiner wrote:
> > > On Tue, Jan 12, 2021 at 09:03:22AM -0800, Roman Gushchin wrote:
> >
On Tue, Jan 12, 2021 at 11:30:11AM -0500, Johannes Weiner wrote:
> When a value is written to a cgroup's memory.high control file, the
> write() context first tries to reclaim the cgroup to size before
> putting the limit in place for the workload. Concurrent charges from
> the workload can keep
On Tue, Jan 12, 2021 at 12:12:47AM +0100, Jann Horn wrote:
> [This is not something I intend to work on myself. But since I
> stumbled over this issue, I figured I should at least document/report
> it, in case anyone is willing to pick it up.]
Hi, Jann!
Thank you very much for this report!
It
On Mon, Jan 11, 2021 at 11:00:17AM -0800, Yang Shi wrote:
> On Wed, Jan 6, 2021 at 4:14 PM Roman Gushchin wrote:
> >
> > On Tue, Jan 05, 2021 at 02:58:08PM -0800, Yang Shi wrote:
> > > The shrinker map management is not really memcg specific, it's just
> > >
keep seeing a consistent view of their usage.
>
> Signed-off-by: Shakeel Butt
> Acked-by: Michal Hocko
Reviewed-by: Roman Gushchin
Thanks!
I've noticed that __memcg_kmem_charge() and __memcg_kmem_uncharge()
are not used anywhere except memcontrol.c. Yet they are not declared
as non-static and are declared in memcontrol.h.
This patch makes them static.
Signed-off-by: Roman Gushchin
---
include/linux/memcontrol.h | 3 ---
mm
On Tue, Jan 05, 2021 at 02:58:14PM -0800, Yang Shi wrote:
> Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
> nr_deferred
> will be used in the following cases:
> 1. Non memcg aware shrinkers
> 2. !CONFIG_MEMCG
It's better to depend on CONFIG_MEMCG_KMEM rather than
On Tue, Jan 05, 2021 at 02:58:08PM -0800, Yang Shi wrote:
> The shrinker map management is not really memcg specific, it's just allocation
In the current form it doesn't look so, especially because each name
has a memcg_ prefix and each function takes a memcg argument.
It begs for some
On Wed, Jan 06, 2021 at 11:50:44AM -0800, Andrew Morton wrote:
> On Tue, 5 Jan 2021 20:22:39 -0800 Roman Gushchin wrote:
>
> > Imran Khan reported a regression in hackbench results caused by the
> > commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab objec
On Tue, Jan 05, 2021 at 10:05:20PM -0800, Shakeel Butt wrote:
> On Tue, Jan 5, 2021 at 8:22 PM Roman Gushchin wrote:
> >
> > Imran Khan reported a regression in hackbench results caused by the
> > commit f2fe7b09a52b ("mm: memcg/slab: charge individual slab ob
On Wed, Jan 06, 2021 at 02:39:05PM +1100, Imran Khan wrote:
> On 6/1/21 2:29 pm, Roman Gushchin wrote:
>
> > On Wed, Jan 06, 2021 at 02:07:12PM +1100, Imran Khan wrote:
> > > On 6/1/21 5:45 am, Roman Gushchin wrote:
> > > > On Tue, Jan 05, 2021 at 10:23
faster,
so the freeing of page-sized kernel allocations (e.g. large kmallocs)
will become faster.
A similar change has been done earlier for the socket memory by
the commit 475d0487a2ad ("mm: memcontrol: use per-cpu stocks for
socket memory uncharging").
Signed-off-by: Roman Gushchin
Rep
On Wed, Jan 06, 2021 at 02:07:12PM +1100, Imran Khan wrote:
>
> On 6/1/21 5:45 am, Roman Gushchin wrote:
> > On Tue, Jan 05, 2021 at 10:23:52AM -0800, Roman Gushchin wrote:
> > > On Tue, Jan 05, 2021 at 04:07:42PM +, Imran Khan wrote:
> > > > While allocati
On Tue, Jan 05, 2021 at 10:23:52AM -0800, Roman Gushchin wrote:
> On Tue, Jan 05, 2021 at 04:07:42PM +, Imran Khan wrote:
> > While allocating objects whose size is multiple of PAGE_SIZE,
> > say kmalloc-4K, we charge one page for extra bytes corresponding
> > to the
.8 kernel.
The difference is quite impressive!
I wonder if you tried smaller values than KMALLOC_MAX_CACHE_SIZE * 2?
Let's say 16 and 32?
KMALLOC_MAX_CACHE_SIZE * 2 makes sense to me, but then the whole construction
with two layer caching is very questionable. Anyway, it's not a reason to not
merge your patch, just something I wanna look at later.
>
> Signed-off-by: Imran Khan
Reviewed-by: Roman Gushchin
Thanks!
SM
> charge bug, so may be worth keeping: but skip if mem_cgroup_disabled().
>
> Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()")
> Signed-off-by: Hugh Dickins
Acked-by: Roman Gushchin
Thanks!
> ---
>
> include/linux/memcontrol.h |2 +-
>
On Tue, Dec 29, 2020 at 10:35:14PM +0800, Feng Tang wrote:
> When profiling memory cgroup involved benchmarking, status update
> sometimes take quite some CPU cycles. Current MEMCG_CHARGE_BATCH
> is used for both charging and statistics/events updating, and is
> set to 32, which may be good for
2%
>
> [1].https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/
> Signed-off-by: Feng Tang
> Cc: Roman Gushchin
> Cc: Johannes Weiner
> ---
> include/linux/page_counter.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff
gt; for cgroup v2") exposed numa stats for the memcg. So fixing the
> file_dirty per-memcg numa stat.
>
> Fixes: 5f9a4f4a7096 ("mm: memcontrol: add the missing numa_stat interface for
> cgroup v2")
> Signed-off-by: Shakeel Butt
> Cc:
Reviewed-by: Roman Gushc
On Thu, Dec 24, 2020 at 12:10:39AM +0200, Mike Rapoport wrote:
> On Wed, Dec 23, 2020 at 08:35:37AM -0800, Roman Gushchin wrote:
> > On Tue, Dec 22, 2020 at 08:06:06PM -0800, Andrew Morton wrote:
> > > On Mon, 21 Dec 2020 09:05:51 -0800 Roman Gushchin wrote:
> > >
>
With the typo fix ("__mod_zone_page_tate")
Reviewed-by: Roman Gushchin
Thanks!
On Tue, Dec 22, 2020 at 08:06:06PM -0800, Andrew Morton wrote:
> On Mon, 21 Dec 2020 09:05:51 -0800 Roman Gushchin wrote:
>
> > Subject: [PATCH v3 1/2] mm: cma: allocate cma areas bottom-up
>
> i386 allmodconfig:
>
> In file included from ./include/vdso/const.h:5,
On Mon, Dec 21, 2020 at 08:33:44PM +, Matthew Wilcox wrote:
> On Mon, Dec 21, 2020 at 11:56:36AM -0800, Hugh Dickins wrote:
> > On Mon, 23 Nov 2020, Andrew Morton wrote:
> > > On Fri, 20 Nov 2020 17:55:22 -0800 syzbot
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > syzbot found the
On Sun, Dec 20, 2020 at 08:48:48AM +0200, Mike Rapoport wrote:
> On Thu, Dec 17, 2020 at 12:12:13PM -0800, Roman Gushchin wrote:
> > Currently cma areas without a fixed base are allocated close to the
> > end of the node. This placement is sub-optimal because of compaction:
>
On Sat, Dec 19, 2020 at 11:52:19PM +0900, Wonhyuk Yang wrote:
> Hi Roman,
>
> On Fri, Dec 18, 2020 at 5:12 AM Roman Gushchin wrote:
> >
> > With kaslr the kernel image is placed at a random place, so starting
> > the bottom-up allocation with the kernel_end can
gether it simplifies the logic.
Signed-off-by: Roman Gushchin
---
mm/memblock.c | 49 ++---
1 file changed, 6 insertions(+), 43 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index b68ee86788af..10bd7d1ef0f4 100644
--- a/mm/memblock.c
++
- start with 4GB, by Mike
Signed-off-by: Roman Gushchin
---
mm/cma.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 7f415d7cda9f..21fd40c092f0 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -337,6 +337,22 @@ int __init cma_declare_contiguous_nid
On Wed, Dec 16, 2020 at 08:59:38AM +1100, Dave Chinner wrote:
> On Tue, Dec 15, 2020 at 02:53:48PM +0100, Johannes Weiner wrote:
> > On Tue, Dec 15, 2020 at 01:09:57PM +1100, Dave Chinner wrote:
> > > On Mon, Dec 14, 2020 at 02:37:15PM -0800, Yang Shi wrote:
> > > > Since memcg_shrinker_map_size
On Tue, Dec 15, 2020 at 11:36:23PM +0200, Mike Rapoport wrote:
> Hi Roman,
>
> On Tue, Dec 15, 2020 at 11:36:15AM -0800, Roman Gushchin wrote:
> > Currently cma areas without a fixed base address are allocated
> > close to the end of the node. This placement is sub-optim
allocation success rates.
Signed-off-by: Roman Gushchin
---
include/linux/memblock.h | 5 +++--
mm/cma.c | 4 ++--
mm/memblock.c| 26 +++---
3 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux
On Tue, Dec 15, 2020 at 07:21:56AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 4 Dec 2020 20:20:05 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got conflicts in:
> >
> > include/linux/memcontrol.h
> > mm/memcontrol.c
> >
> > between
On Wed, Dec 09, 2020 at 10:31:55AM +0800, Muchun Song wrote:
> On Wed, Dec 9, 2020 at 10:21 AM Roman Gushchin wrote:
> >
> > On Tue, Dec 08, 2020 at 05:51:32PM +0800, Muchun Song wrote:
> > > The vmstat threshold is 32 (MEMCG_CHARGE_BATCH), so the type of s32
> >
On Tue, Dec 08, 2020 at 06:21:18PM -0800, Roman Gushchin wrote:
> On Tue, Dec 08, 2020 at 05:51:32PM +0800, Muchun Song wrote:
> > The vmstat threshold is 32 (MEMCG_CHARGE_BATCH), so the type of s32
> > of lruvec_stat_cpu is enough. And introduce struct per_cpu_lruvec_stat
> &g
On Tue, Dec 08, 2020 at 05:51:32PM +0800, Muchun Song wrote:
> The vmstat threshold is 32 (MEMCG_CHARGE_BATCH), so the type of s32
> of lruvec_stat_cpu is enough. And introduce struct per_cpu_lruvec_stat
> to optimize memory usage.
>
> The size of struct lruvec_stat is 304 bytes on 64 bits
Song
> Acked-by: Michal Hocko
Reviewed-by: Roman Gushchin
Thanks!
> ---
> mm/memcontrol.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b80328f52fb4..8818bf64d6fe 100644
> --- a/mm/memcontro
On Mon, Dec 07, 2020 at 11:46:22AM -0800, Roman Gushchin wrote:
> On Sun, Dec 06, 2020 at 06:14:48PM +0800, Muchun Song wrote:
> > the global and per-node counters are stored in pages, however memcg
> > and lruvec counters are stored in bytes. This scheme looks weird.
> >
On Mon, Dec 07, 2020 at 04:02:54PM +0100, Michal Hocko wrote:
> On Mon 07-12-20 22:52:30, Muchun Song wrote:
> > On Mon, Dec 7, 2020 at 9:00 PM Michal Hocko wrote:
> > >
> > > On Sun 06-12-20 18:14:39, Muchun Song wrote:
> > > > Hi,
> > > >
> > > > This patch series is aimed to convert all THP
On Sun, Dec 06, 2020 at 06:14:48PM +0800, Muchun Song wrote:
> the global and per-node counters are stored in pages, however memcg
> and lruvec counters are stored in bytes. This scheme looks weird.
> So convert all vmstat slab counters to bytes.
There is a reason for this weird scheme:
percpu
> variable of size is already the value of slab_unreclaimable. So we
> > do not need to read again. Simplify the code here.
> >
> > Signed-off-by: Muchun Song
> > Acked-by: Roman Gushchin
>
> I agree that ignoring the ratio right now is not very pretty, b
On Thu, Dec 03, 2020 at 02:49:00PM -0800, Yang Shi wrote:
> On Thu, Dec 3, 2020 at 12:07 PM Roman Gushchin wrote:
> >
> > On Thu, Dec 03, 2020 at 10:03:44AM -0800, Yang Shi wrote:
> > > On Wed, Dec 2, 2020 at 8:54 PM Yang Shi wrote:
> > > >
> > > &g
On Wed, Dec 02, 2020 at 08:59:40PM -0800, Yang Shi wrote:
> On Wed, Dec 2, 2020 at 7:01 PM Roman Gushchin wrote:
> >
> > On Wed, Dec 02, 2020 at 10:27:20AM -0800, Yang Shi wrote:
> > > Currently registered shrinker is indicated by non-NULL
> > > shrinker->nr_d
101 - 200 of 2791 matches
Mail list logo
