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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
