Hello, On Thu, Aug 04, 2016 at 05:58:42PM +0000, Joshi, Venu wrote: > 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 Your application may be doing that but what's preventing userland from being in the middle of racing cgroup operations? This may work for a particular setup but given the current interface it's difficult to expose something like this as a part of general API. > 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 This isn't a particularly good way to use cgroup because migrations are expensive and possibly high-latency operations. It often is that there are trade-offs between migration overhead and hot path overhead and obviously lowering hot path overhead takes precedence. Another factor is that some resources are stateful and migrating don't migrate the existing charges messing up accounting. From cgroup's pov, it'd be better to have a per-cgroup workerpool and dispatching jobs to them accordingly. > 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). I'm not sure how performing operations from kernel improves the situation tho. 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
