From: Waiman Long <llong@redhat.com>
To: Roman Gushchin <guro@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, Shakeel Butt <shakeelb@google.com>,
Muchun Song <songmuchun@bytedance.com>,
Alex Shi <alex.shi@linux.alibaba.com>,
Chris Down <chris@chrisdown.name>,
Yafang Shao <laoar.shao@gmail.com>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Wei Yang <richard.weiyang@gmail.com>,
Masayoshi Mizuma <msys.mizuma@gmail.com>
Subject: Re: [PATCH 5/5] mm/memcg: Optimize user context object stock access
Date: Mon, 12 Apr 2021 15:58:46 -0400 [thread overview]
Message-ID: <49c03fb0-be46-5288-2c4c-6ad5ad194b4c@redhat.com> (raw)
In-Reply-To: <YHSXvQVvzHu26u7H@carbon.dhcp.thefacebook.com>
On 4/12/21 2:55 PM, Roman Gushchin wrote:
> On Fri, Apr 09, 2021 at 07:18:42PM -0400, Waiman Long wrote:
>> Most kmem_cache_alloc() calls are from user context. With instrumentation
>> enabled, the measured amount of kmem_cache_alloc() calls from non-task
>> context was about 0.01% of the total.
>>
>> The irq disable/enable sequence used in this case to access content
>> from object stock is slow. To optimize for user context access, there
>> are now two object stocks for task context and interrupt context access
>> respectively.
>>
>> The task context object stock can be accessed after disabling preemption
>> which is cheap in non-preempt kernel. The interrupt context object stock
>> can only be accessed after disabling interrupt. User context code can
>> access interrupt object stock, but not vice versa.
>>
>> The mod_objcg_state() function is also modified to make sure that memcg
>> and lruvec stat updates are done with interrupted disabled.
>>
>> The downside of this change is that there are more data stored in local
>> object stocks and not reflected in the charge counter and the vmstat
>> arrays. However, this is a small price to pay for better performance.
> I agree, the 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 <guro@fb.com>
>
> 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.
This patchset is based on the code in Linus' tree. I had applied the
patchset to linux-next to see if there was any conflicts. Two of the
patches had minor fuzzes around the edge but no actual merge conflict
for now.
Cheers,
Longman
next prev parent reply other threads:[~2021-04-12 19:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 23:18 [PATCH 0/5] mm/memcg: Reduce kmemcache memory accounting overhead Waiman Long
2021-04-09 23:18 ` [PATCH 1/5] mm/memcg: Pass both memcg and lruvec to mod_memcg_lruvec_state() Waiman Long
2021-04-12 18:04 ` Roman Gushchin
2021-04-12 19:24 ` Waiman Long
2021-04-12 19:22 ` Shakeel Butt
2021-04-09 23:18 ` [PATCH 2/5] mm/memcg: Introduce obj_cgroup_uncharge_mod_state() Waiman Long
2021-04-12 15:50 ` Shakeel Butt
2021-04-12 18:10 ` Roman Gushchin
2021-04-09 23:18 ` [PATCH 3/5] mm/memcg: Cache vmstat data in percpu memcg_stock_pcp Waiman Long
2021-04-12 18:22 ` Roman Gushchin
2021-04-12 19:30 ` Waiman Long
2021-04-09 23:18 ` [PATCH 4/5] mm/memcg: Separate out object stock data into its own struct Waiman Long
2021-04-12 18:53 ` Roman Gushchin
2021-04-09 23:18 ` [PATCH 5/5] mm/memcg: Optimize user context object stock access Waiman Long
2021-04-12 18:55 ` Roman Gushchin
2021-04-12 19:58 ` Waiman Long [this message]
2021-04-10 1:51 ` [PATCH 0/5] mm/memcg: Reduce kmemcache memory accounting overhead Roman Gushchin
2021-04-12 14:03 ` Waiman Long
2021-04-12 17:47 ` Roman Gushchin
2021-04-12 19:20 ` Waiman Long
2021-04-12 19:05 ` Roman Gushchin
2021-04-12 19:51 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49c03fb0-be46-5288-2c4c-6ad5ad194b4c@redhat.com \
--to=llong@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@linux.alibaba.com \
--cc=alexander.h.duyck@linux.intel.com \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=msys.mizuma@gmail.com \
--cc=penberg@kernel.org \
--cc=richard.weiyang@gmail.com \
--cc=rientjes@google.com \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).