Resend with the right cc email address. -----Original Message----- From: Joshi, Venu Sent: Thursday, August 04, 2016 10:59 AM To: 'tj@xxxxxxxxxx' Cc: 'groups@xxxxxxxxxxxxxxx' Subject: RE: cgroup kernel API question Thanks. Our database server creates a sub directory (say TeradataCgroup) under the root cgroup and manages all processes/tasks and ensures proper synchronization across multiple accessors. These processes/tasks may create further sub-directories under /root-cgroup/TeradataCgroup/ with different cpu.share values. The tasks constantly migrate to different cgroups at different hierarchical levels based on the priority of the user SQL/query/request. All this happens when the tasks have trapped into the kernel mode via a syscall. Our Teradata Database server is a highly parallel application and uses kernel mode synchronization APIs (spinlocks etc.,) via a kernel mode driver extension to achieve synchronization. Hence we mostly try to use Kernel API for key operations. In our application, cgroup operations are never done in userland to avoid the problem you mentioned below (severely confusing userland that is trying to use the cgroups too). Thanks Joshi -----Original Message----- From: Tejun Heo [mailto:htejun@xxxxxxxxx] On Behalf Of tj@xxxxxxxxxx Sent: Thursday, August 04, 2016 7:35 AM To: Joshi, Venu Subject: Re: cgroup kernel API question Hello, Joshi. On Wed, Aug 03, 2016 at 09:59:14PM +0000, Joshi, Venu wrote: > I've seen the extensive work that you've done with cgroups (v1 and v2). > > I work at Teradata and our database server uses cgroups pretty > extensively. We have a kernel driver that directly calls sched/cgroup > API to create cgroups , assign tasks to these groups, set shares for > these cgroups. However, there is a limited support for Kernel drivers > to directly use cgroups (and we have to hack around these unexported > functions to call them in our kernel driver). > > Do you know if there are any requests to provide an interface to work > with cgroups in a kernel driver. There are multiple options available > for user mode applications to use the cgroups (system, libcgroup etc.) The inherent problem there is that cgroup itself doesn't provide any synchronization mechanisms among multiple accessors and most operations are multi-step. So, if you add in-kernel cgroup operations, that can severely confuse userland which is trying to use cgroup. I can't tell much without knowing details of your usage, but it's likely that there is a better of handling the issue than directly initiating cgroup operations from kernel side. Also, please cc cgroups@xxxxxxxxxxxxxxx in future messages. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
