Date: Sun, 20 Mar 2016 14:10:38 -0400
From: Tejun Heo <tj@kernel.org>
To: Bandan Das <bsd@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, mst@redhat.com,
        jiangshanlai@gmail.com, RAPOPORT@il.ibm.com
Subject: Re: [RFC PATCH 0/4] cgroup aware workqueues
Message-ID: <20160320181038.GQ20028@mtj.duckdns.org>
References: <1458339291-4093-1-git-send-email-bsd@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1458339291-4093-1-git-send-email-bsd@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1753
Lines: 45

Hello,

On Fri, Mar 18, 2016 at 06:14:47PM -0400, Bandan Das wrote:
> These changes don't populate the "numa awareness" fields/attrs and
> unlike unbounded numa worker pools, cgroup worker pools are created
> on demand. Every work request could potentially have a new cgroup

Hmmm... I don't get it.  Why would this be exclusive with numa
support?  Can't cgroup be just another attribute in addition to numa?

> aware pool created for it based on the combination of cgroups it's attached
> to. However, workqueues themselves are incognizant of the actual cgroups -
> they rely on the cgroups provided helper functions either for 1. a match
> of all the cgroups or 2. to attach a worker thread to all cgroups of
> a userspace task. We do maintain a list of cgroup aware pools so that
> when a new request comes in and a suitable worker pool needs to be
> found, we search the list first before creating a new one. A worker
> pool also stores a a list of all "task owners" - a list of processes
> that we are serving currently.

Why is this separate from the normal lookup mechanism?  Can't it be
hashed together?

> Todo:
> What about bounded workqueues ?

I don't think it'd matter.  This is only interesting for work items
which may consume a significant amount of resources, which shouldn't
be served by per-cpu workers anyway.

> What happens when cgroups of a running process changes ?

Existing work items will be served with the old association.  New work
items will be served with the new association.  This is consistent
with how other attributes are handled too.

> Better performance numbers ? (although the onese above don't look bad)

Where is performance regression coming from?  Why is there *any*
performance penalty?

Thanks.

-- 
tejun