[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <YLriZxiWo+2hMI7g@slm.duckdns.org>
Date: Fri, 4 Jun 2021 22:33:11 -0400
From: Tejun Heo <tj@...nel.org>
To: Hillf Danton <hdanton@...a.com>
Cc: Shakeel Butt <shakeelb@...gle.com>,
Johannes Weiner <hannes@...xchg.org>,
Muchun Song <songmuchun@...edance.com>,
Michal Hocko <mhocko@...nel.org>, Roman Gushchin <guro@...com>,
Michal Koutný <mkoutny@...e.com>,
Huang Ying <ying.huang@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] memcg: periodically flush the memcg stats
On Sat, Jun 05, 2021 at 09:54:21AM +0800, Hillf Danton wrote:
> The cond_resched() in cgroup_rstat_flush_locked() matches its appearence in
> your post [1]. So does unbound IMHO.
Ah yeah, this either needs CPU_INTENSIVE or UNBOUND, prolly the latter is
better.
> And the short stuff [2] looks to me like it is incorrect to queue a work
> acquiring mutex lock on to the system_wq. IOW the unbound wq is the right
> thing for any work that might sleep.
This part doesn't make sense. Blocking from per-cpu workqueue is completely
fine. What's not fine is consuming a lot of CPU cycles.
Thanks.
--
tejun
Powered by blists - more mailing lists