From: Pavan Kondeti <firstname.lastname@example.org> To: Tejun Heo <email@example.com> Cc: firstname.lastname@example.org, email@example.com, Zefan Li <firstname.lastname@example.org>, Johannes Weiner <email@example.com>, Quentin Perret <firstname.lastname@example.org>, Wei Wang <email@example.com> Subject: Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup Date: Wed, 7 Apr 2021 07:08:56 +0530 [thread overview] Message-ID: <20210407013856.GC21941@codeaurora.org> (raw) In-Reply-To: <YGyJHAlLKqng2WeS@slm.duckdns.org> On Tue, Apr 06, 2021 at 12:15:24PM -0400, Tejun Heo wrote: > Hello, > > On Tue, Apr 06, 2021 at 08:57:15PM +0530, Pavan Kondeti wrote: > > Yeah. The workqueue attrs comes in handy to reduce the nice/prio of a > > background workqueue if we identify that it is cpu intensive. However, this > > needs case by case analysis, tweaking etc. If there is no other alternative, > > we might end up chasing the background workers and reduce their nice value. > > There shouldn't be that many workqueues that consume a lot of cpu cycles. > The usual culprit is kswapd, IO related stuff (writeback, encryption), so it > shouldn't be a long list and we want them identified anyway. > Sure. I have not done a complete study on which workers in our system can compete with important tasks in other cgroups. We will have to do that to adjust the workqueue priority so that the impact can be minimized. > > The problem at our hand (which you might be knowing already) is that, lets say > > we have 2 cgroups in our setup and we want to prioritize UX over background. > > IOW, reduce the cpu.shares of background cgroup. This helps in prioritizing > > Task-A and Task-B over Task-X and Task-Y. However, each individual kworker > > can potentially have CPU share equal to the entire UX cgroup. > > > > -kworker/0:0 > > -kworker/1:0 > > - UX > > ----Task-A > > ----Task-B > > - background > > ----Task-X > > ----Task-Y > > Hence we want to move all kernel threads to another cgroup so that this cgroup > > will have CPU share equal to UX. > > > > The patch presented here allows us to create the above setup. Any other > > alternative approaches to achieve the same without impacting any future > > designs/requirements? > > Not quite the same but we already have > /sys/devices/virtual/workqueue/cpumask which affects all unbound workqueues, > so maybe a global default priority knob would help here? > yeah, not exactly what we are looking for. It gives us the abiility to restrict the priority of all unbound workqueues at the expense of not being able to prioritize one workqueue over another workqueue. Thanks, Pavan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2021-04-07 1:39 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-06 13:04 Pavankumar Kondeti 2021-04-06 13:36 ` Tejun Heo 2021-04-06 15:27 ` Pavan Kondeti 2021-04-06 16:15 ` Tejun Heo 2021-04-07 1:38 ` Pavan Kondeti [this message] 2021-04-14 22:00 ` Wei Wang -- strict thread matches above, loose matches on Subject: below -- 2021-04-06 10:59 Pavankumar Kondeti 2021-04-06 12:10 ` Quentin Perret 2021-04-06 13:00 ` Pavan Kondeti
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=20210407013856.GC21941@codeaurora.org \ --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 \ --subject='Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.