From: Daniel Jordan <email@example.com> To: Michal Hocko <firstname.lastname@example.org> Cc: Johannes Weiner <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Tejun Heo <email@example.com>, Roman Gushchin <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high Date: Wed, 19 Feb 2020 16:41:12 -0500 Message-ID: <email@example.com> (raw) In-Reply-To: <20200219195332.GE11847@dhcp22.suse.cz> On Wed, Feb 19, 2020 at 08:53:32PM +0100, Michal Hocko wrote: > On Wed 19-02-20 14:16:18, Johannes Weiner wrote: > > On Wed, Feb 19, 2020 at 07:37:31PM +0100, Michal Hocko wrote: > > > On Wed 19-02-20 13:12:19, Johannes Weiner wrote: > > > > This patch adds asynchronous reclaim to the memory.high cgroup limit > > > > while keeping direct reclaim as a fallback. In our testing, this > > > > eliminated all direct reclaim from the affected workload. > > > > > > Who is accounted for all the work? Unless I am missing something this > > > just gets hidden in the system activity and that might hurt the > > > isolation. I do see how moving the work to a different context is > > > desirable but this work has to be accounted properly when it is going to > > > become a normal mode of operation (rather than a rare exception like the > > > existing irq context handling). > > > > Yes, the plan is to account it to the cgroup on whose behalf we're > > doing the work. How are you planning to do that? I've been thinking about how to account a kernel thread's CPU usage to a cgroup on and off while working on the parallelizing Michal mentions below. A few approaches are described here: https://firstname.lastname@example.org/ > shows that the amount of the work required for the high limit reclaim > can be non-trivial. Somebody has to do that work and we cannot simply > allow everybody else to pay for that. > > > The problem is that we have a general lack of usable CPU control right > > now - see Rik's work on this: https://lkml.org/lkml/2019/8/21/1208. > > For workloads that are contended on CPU, we cannot enable the CPU > > controller because the scheduling latencies are too high. And for > > workloads that aren't CPU contended, well, it doesn't really matter > > where the reclaim cycles are accounted to. > > > > Once we have the CPU controller up to speed, we can add annotations > > like these to account stretches of execution to specific > > cgroups. There just isn't much point to do it before we can actually > > enable CPU control on the real workloads where it would matter. Which annotations do you mean? I didn't see them when skimming through Rik's work or in this patch.
next prev parent reply index Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-19 18:12 Johannes Weiner 2020-02-19 18:37 ` Michal Hocko 2020-02-19 19:16 ` Johannes Weiner 2020-02-19 19:53 ` Michal Hocko 2020-02-19 21:17 ` Johannes Weiner 2020-02-20 9:46 ` Michal Hocko 2020-02-20 14:41 ` Johannes Weiner 2020-02-19 21:41 ` Daniel Jordan [this message] 2020-02-19 22:08 ` Johannes Weiner 2020-02-20 15:45 ` Daniel Jordan 2020-02-20 15:56 ` Tejun Heo 2020-02-20 18:23 ` Daniel Jordan 2020-02-20 18:45 ` Tejun Heo 2020-02-20 19:55 ` Daniel Jordan 2020-02-20 20:54 ` Tejun Heo 2020-02-19 19:17 ` Chris Down 2020-02-19 19:31 ` Andrew Morton 2020-02-19 21:33 ` Johannes Weiner 2020-02-26 20:25 ` Shakeel Butt 2020-02-26 22:26 ` Johannes Weiner 2020-02-26 23:36 ` Shakeel Butt 2020-02-26 23:46 ` Johannes Weiner 2020-02-27 0:12 ` Yang Shi 2020-02-27 2:42 ` Shakeel Butt 2020-02-27 9:58 ` Michal Hocko 2020-02-27 12:50 ` Johannes Weiner 2020-02-26 23:59 ` Yang Shi 2020-02-27 2:36 ` Shakeel Butt
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ firstname.lastname@example.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git