From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Subject: Re: [RFC v2 0/5] cgroup-aware unbound workqueues Date: Thu, 6 Jun 2019 09:15:26 +0300 Message-ID: <20190606061525.GD23056@rapoport-lnx> References: <20190605133650.28545-1-daniel.m.jordan@oracle.com> <20190605135319.GK374014@devbig004.ftw2.facebook.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20190605135319.GK374014@devbig004.ftw2.facebook.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: Daniel Jordan , hannes@cmpxchg.org, jiangshanlai@gmail.com, lizefan@huawei.com, bsd@redhat.com, dan.j.williams@intel.com, dave.hansen@intel.com, juri.lelli@redhat.com, mhocko@kernel.org, peterz@infradead.org, steven.sistare@oracle.com, tglx@linutronix.de, tom.hromatka@oracle.com, vdavydov.dev@gmail.com, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Hi Tejun, On Wed, Jun 05, 2019 at 06:53:19AM -0700, Tejun Heo wrote: > Hello, Daniel. > > On Wed, Jun 05, 2019 at 09:36:45AM -0400, Daniel Jordan wrote: > > My use case for this work is kernel multithreading, the series formerly known > > as ktask[2] that I'm now trying to combine with padata according to feedback > > from the last post. Helper threads in a multithreaded job may consume lots of > > resources that aren't properly accounted to the cgroup of the task that started > > the job. > > Can you please go into more details on the use cases? If I remember correctly, the original Bandan's work was about using workqueues instead of kthreads in vhost. > For memory and io, we're generally going for remote charging, where a > kthread explicitly says who the specific io or allocation is for, > combined with selective back-charging, where the resource is charged > and consumed unconditionally even if that would put the usage above > the current limits temporarily. From what I've been seeing recently, > combination of the two give us really good control quality without > being too invasive across the stack. > > CPU doesn't have a backcharging mechanism yet and depending on the use > case, we *might* need to put kthreads in different cgroups. However, > such use cases might not be that abundant and there may be gotaches > which require them to be force-executed and back-charged (e.g. fs > compression from global reclaim). > > Thanks. > > -- > tejun > -- Sincerely yours, Mike.