Have sane default values for cpusets
in [Kernel]
|
Prev: [PATCH] remove bogus #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT for debug_kmap_atomic()
Next: [pm] resume from s3 oops? (last checked on rc6)
From: Dhaval Giani on 12 May 2010 10:30 On Wed, May 12, 2010 at 4:20 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-05-12 at 16:13 +0200, Dhaval Giani wrote: >> What you are saying is that an application >> programmer who wants to just use memory cgroups should also care about >> cpusets and just about countless other cgroup subsystems that can >> exist. > > That's exactly what he says if he mounts them together. > No. That's not under his control. Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Safranek on 12 May 2010 10:50 On 05/12/2010 04:20 PM, Peter Zijlstra wrote: > On Wed, 2010-05-12 at 16:13 +0200, Dhaval Giani wrote: >> What you are saying is that an application >> programmer who wants to just use memory cgroups should also care about >> cpusets and just about countless other cgroup subsystems that can >> exist. > > That's exactly what he says if he mounts them together. No, the programmer does not mount anything. Programmer writes application which wants to create a subgroup. System admin is the one who decides what is mounted how. And the programmer (=me) needs a way how to reliably create a subgroup, without knowing details about all controllers. E.g. 'blkio' controller is quite new one, old applications do now know anything about it, yet according to your idea, the application *must* provide sane defaults to it. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dhaval Giani on 12 May 2010 13:50 On Wed, May 12, 2010 at 7:38 PM, James Kosin <jkosin(a)intcomgrp.com> wrote: > On 5/12/2010 10:40 AM, Jan Safranek wrote: > > On 05/12/2010 04:20 PM, Peter Zijlstra wrote: > > On Wed, 2010-05-12 at 16:13 +0200, Dhaval Giani wrote: > > What you are saying is that an application > programmer who wants to just use memory cgroups should also care about > cpusets and just about countless other cgroup subsystems that can > exist. > > That's exactly what he says if he mounts them together. > > No, the programmer does not mount anything. Programmer writes application > which wants to create a subgroup. System admin is the one who decides what > is mounted how. And the programmer (=me) needs a way how to reliably create > a subgroup, without knowing details about all controllers. E.g. 'blkio' > controller is quite new one, old applications do now know anything about it, > yet according to your idea, the application *must* provide sane defaults to > it. > > Jan > > > Jan, > > I think sane defaults should be enforced only if the application actively > uses the device.� Your right in that you don't want to have to guess as to > which devices are mounted as long as you don't touch the devices that aren't > mounted everything should be okay and work for the specific device or mount > you are working with� (which by the way you need to know!!!).... > I seem to get the impression that there is a miscommunication here. We are talking about the cgroups feature here (more details are available at http://www.mjmwired.net/kernel/Documentation/cgroups.txt ). We really are not talking about devices, but about specific cgroup subsystems which can be mounted together, and are not under the control of the programmer. > PS: Providing a set of defaults on creation may lead to a security > problem... just an afterthought. > Which is why you have *sane* defaults. Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Kosin on 12 May 2010 14:00 On 5/12/2010 1:42 PM, Dhaval Giani wrote: > > I seem to get the impression that there is a miscommunication here. We > are talking about the cgroups feature here (more details are available > at http://www.mjmwired.net/kernel/Documentation/cgroups.txt ). We > really are not talking about devices, but about specific cgroup > subsystems which can be mounted together, and are not under the > control of the programmer. > > > > Dhaval > > Thanks for clearing that up. It looks like they are not under the control of the programmer on purpose. It is not outlined in the description of how to use this feature. The tasks have to be added separately by an administrator that is operating the system to tune performance and to provide resources where most needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chris Friesen on 12 May 2010 14:10
On 05/12/2010 11:58 AM, James Kosin wrote: > Thanks for clearing that up. > It looks like they are not under the control of the programmer on > purpose. It is not outlined in the description of how to use this feature. > The tasks have to be added separately by an administrator that is > operating the system to tune performance and to provide resources where > most needed. Depending on the type of system, they may or may not be under the control of the programmer. In an embedded environment, the programmer is the administrator and generally has control over how the groups are set up. On a more generic time-sharing system it's likely that the individual programmer won't have control over the groups. Something I haven't tried is whether or not it's possible to set ownership/permissions on subtrees within the cgroup hierarchy to allow unprivileged users/groups to control their own tasks (basically letting them prioritize their own jobs without being able to affect anything else). Does anyone know if this sort of thing is possible? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |