Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Wed, Feb 20, 2008 at 10:55:07AM -0600, [EMAIL PROTECTED] wrote: > Quoting Nick Andrew ([EMAIL PROTECTED]): > > On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: > > Maybe > Control Groups enable processes to be grouped into "cgroups" > to facilitate tracking and resource management. For example > a cgroup can tie a set of processes to a set of cpus using > "cpusets". That is much nicer, thanks. > > When enabled, a new filesystem type "cgroup" is available > > and can be mounted to control cpusets and other > > resource/behaviour controllers. I thought of something better to say than this. Enabling a new pseudo filesystem is interesting, but it's not the main point. Now: config CGROUPS bool "Control Group support" help - This option will let you use process cgroup subsystems - such as Cpusets + Control Groups enable processes to be grouped into "cgroups" + to facilitate tracking and resource management. For example + a cgroup can tie a set of processes to a set of CPUs using + "cpusets". - Say N if unsure. + See for more information. + + If you say Y here, you probably want to enable one or + more of the cgroup subsystem options below. + + If unsure, say N. Regarding GROUP_SCHED and CGROUP_SCHED I am confused, what is the difference between these two options? config GROUP_SCHED bool "Group CPU scheduler" default y help This feature enables the CPU scheduler to recognize task groups and control CPU bandwidth allocation to such task groups. See for more information. [...] config CGROUP_SCHED bool "Control groups" depends on CGROUPS help This option allows you to create arbitrary task groups using the "cgroup" pseudo filesystem and control the CPU bandwidth allocated to each such task group. See for more information on the "cgroup" pseudo filesystem. Also with the titles, IMHO "Control Group support" is semantically equivalent to "Control groups" so I am doubly confused. Nick. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Quoting Nick Andrew ([EMAIL PROTECTED]): > On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: > > On Feb 19, 2008 7:12 AM, Nick Andrew <[EMAIL PROTECTED]> wrote: > > > config CGROUPS > > > [...] > > > + When enabled, a new filesystem type "cgroup" is available > > > + and can be mounted to control cpusets. > > How about: > > ... cpusets and other resource/behaviour controllers. > > Ok I added that. This is what I have now: > > > config CGROUPS > bool "Control Group support" > help > Control Groups enables processes to be tracked and grouped > into "cgroups". This enables you, for example, to associate Maybe Control Groups enable processes to be grouped into "cgroups" to facilitate tracking and resource management. For example a cgroup can tie a set of processes to a set of cpus using "cpusets". > When enabled, a new filesystem type "cgroup" is available > and can be mounted to control cpusets and other > resource/behaviour controllers. > > See for more information. > > If unsure, say N. > > > I don't think that description is as clear as it could be. From > the non-kernel-developer point of view, that is. I'll read > Documentation/cgroups.txt more thoroughly and see if I can come > up with a better description. > > Re "other resource/behaviour controllers", what in particular? > I take it that our current controllers are cpusets, scheduler, > CPU accounting and Resource counters? > > Nick. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Nick wrote: > Ok, I had just picked up on the "legacy" word in the option title > and assumed that it meant deprecated. Just because something's old (and some newer equivalent exists) doesn't mean we're making funeral arrangements for it yet. Paul "old man" Jackson -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Tue, Feb 19, 2008 at 09:39:58AM -0600, Paul Jackson wrote: > I don't think /proc//cpuset (PROC_PID_CPUSET) is, or should be, > deprecated. Ok, I had just picked up on the "legacy" word in the option title and assumed that it meant deprecated. This is what I've got now: config PROC_PID_CPUSET bool "Include legacy /proc//cpuset file" depends on CPUSETS default y + help + This option provides the /proc//cpuset file. + + This file contains the name of the cpuset in which + the process is executing. For more information, see + + + If unsure, say Y. In general, are option titles fragile? For example, if I were to submit a patch which changes an option's title string, is this likely to break something or somebody? Nick. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Tue, Feb 19, 2008 at 09:39:58AM -0600, Paul Jackson wrote: I don't think /proc/pid/cpuset (PROC_PID_CPUSET) is, or should be, deprecated. Ok, I had just picked up on the legacy word in the option title and assumed that it meant deprecated. This is what I've got now: config PROC_PID_CPUSET bool Include legacy /proc/pid/cpuset file depends on CPUSETS default y + help + This option provides the /proc/pid/cpuset file. + + This file contains the name of the cpuset in which + the process is executing. For more information, see + file:Documentation/cpusets.txt + + If unsure, say Y. In general, are option titles fragile? For example, if I were to submit a patch which changes an option's title string, is this likely to break something or somebody? Nick. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Nick wrote: Ok, I had just picked up on the legacy word in the option title and assumed that it meant deprecated. Just because something's old (and some newer equivalent exists) doesn't mean we're making funeral arrangements for it yet. Paul old man Jackson -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.940.382.4214 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Quoting Nick Andrew ([EMAIL PROTECTED]): On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: On Feb 19, 2008 7:12 AM, Nick Andrew [EMAIL PROTECTED] wrote: config CGROUPS [...] + When enabled, a new filesystem type cgroup is available + and can be mounted to control cpusets. How about: ... cpusets and other resource/behaviour controllers. Ok I added that. This is what I have now: config CGROUPS bool Control Group support help Control Groups enables processes to be tracked and grouped into cgroups. This enables you, for example, to associate Maybe Control Groups enable processes to be grouped into cgroups to facilitate tracking and resource management. For example a cgroup can tie a set of processes to a set of cpus using cpusets. When enabled, a new filesystem type cgroup is available and can be mounted to control cpusets and other resource/behaviour controllers. See file:Documentation/cgroups.txt for more information. If unsure, say N. I don't think that description is as clear as it could be. From the non-kernel-developer point of view, that is. I'll read Documentation/cgroups.txt more thoroughly and see if I can come up with a better description. Re other resource/behaviour controllers, what in particular? I take it that our current controllers are cpusets, scheduler, CPU accounting and Resource counters? Nick. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Wed, Feb 20, 2008 at 10:55:07AM -0600, [EMAIL PROTECTED] wrote: Quoting Nick Andrew ([EMAIL PROTECTED]): On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: Maybe Control Groups enable processes to be grouped into cgroups to facilitate tracking and resource management. For example a cgroup can tie a set of processes to a set of cpus using cpusets. That is much nicer, thanks. When enabled, a new filesystem type cgroup is available and can be mounted to control cpusets and other resource/behaviour controllers. I thought of something better to say than this. Enabling a new pseudo filesystem is interesting, but it's not the main point. Now: config CGROUPS bool Control Group support help - This option will let you use process cgroup subsystems - such as Cpusets + Control Groups enable processes to be grouped into cgroups + to facilitate tracking and resource management. For example + a cgroup can tie a set of processes to a set of CPUs using + cpusets. - Say N if unsure. + See file:Documentation/cgroups.txt for more information. + + If you say Y here, you probably want to enable one or + more of the cgroup subsystem options below. + + If unsure, say N. Regarding GROUP_SCHED and CGROUP_SCHED I am confused, what is the difference between these two options? config GROUP_SCHED bool Group CPU scheduler default y help This feature enables the CPU scheduler to recognize task groups and control CPU bandwidth allocation to such task groups. See file:Documentation/sched-design-CFS.txt for more information. [...] config CGROUP_SCHED bool Control groups depends on CGROUPS help This option allows you to create arbitrary task groups using the cgroup pseudo filesystem and control the CPU bandwidth allocated to each such task group. See file:Documentation/cgroups.txt for more information on the cgroup pseudo filesystem. Also with the titles, IMHO Control Group support is semantically equivalent to Control groups so I am doubly confused. Nick. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Feb 19, 2008 6:54 PM, Nick Andrew <[EMAIL PROTECTED]> wrote: > > config CGROUPS > bool "Control Group support" > help > Control Groups enables processes to be tracked and grouped > into "cgroups". This enables you, for example, to associate > cgroups with certain CPU sets using "cpusets". > > When enabled, a new filesystem type "cgroup" is available > and can be mounted to control cpusets and other > resource/behaviour controllers. > > See for more information. > > If unsure, say N. > > > I don't think that description is as clear as it could be. From > the non-kernel-developer point of view, that is. Originally this wasn't a user-selectable config value, it was auto-selected by any subsystem that needed it. I think that was nicer from the user-experience, and it would eliminate the need for this documentation but there were concerns that this triggered unspecified brokenness in the Kbuild system. > > Re "other resource/behaviour controllers", what in particular? > I take it that our current controllers are cpusets, scheduler, > CPU accounting and Resource counters? Resource counters aren't a resource controller, they're a helper library. The others are good examples, as is the memory controller that's just been added to 2.6.25. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: > On Feb 19, 2008 7:12 AM, Nick Andrew <[EMAIL PROTECTED]> wrote: > > config CGROUPS > > [...] > > + When enabled, a new filesystem type "cgroup" is available > > + and can be mounted to control cpusets. > How about: > ... cpusets and other resource/behaviour controllers. Ok I added that. This is what I have now: config CGROUPS bool "Control Group support" help Control Groups enables processes to be tracked and grouped into "cgroups". This enables you, for example, to associate cgroups with certain CPU sets using "cpusets". When enabled, a new filesystem type "cgroup" is available and can be mounted to control cpusets and other resource/behaviour controllers. See for more information. If unsure, say N. I don't think that description is as clear as it could be. From the non-kernel-developer point of view, that is. I'll read Documentation/cgroups.txt more thoroughly and see if I can come up with a better description. Re "other resource/behaviour controllers", what in particular? I take it that our current controllers are cpusets, scheduler, CPU accounting and Resource counters? Nick. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Feb 19, 2008 7:12 AM, Nick Andrew <[EMAIL PROTECTED]> wrote: > config CGROUPS > bool "Control Group support" > help > - This option will let you use process cgroup subsystems > - such as Cpusets > + Control Groups enables processes to be tracked and grouped > + into "cgroups". This enables you, for example, to associate > + cgroups with certain CPU sets using "cpusets". > > - Say N if unsure. > + When enabled, a new filesystem type "cgroup" is available > + and can be mounted to control cpusets. How about: ... cpusets and other resource/behaviour controllers. Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Thanks for doing this, Nick. One area looks like some details need working. Nick Andrew wrote: > config PROC_PID_CPUSET > bool "Include legacy /proc//cpuset file" > depends on CPUSETS > default y > + help > + This option provides the legacy /proc//cpuset file. > + > + It has been deprecated in favour of an additional line > + in /proc//status showing on which CPUs a process > + may be scheduled. I don't think /proc//cpuset (PROC_PID_CPUSET) is, or should be, deprecated. Actually, I'd be inclined toward removing this CONFIG option, and making /proc//cpuset a non-optional consequence of enabling cpusets ... so I'm adding Paul Menage to the CC list, in case he has thoughts or insights on this. The duplication of this bit of information between both /proc//cpuset and one line of /proc//status is a minor and harmless wart, resulting from the evolution of cgroups from cpusets, that is not worth bothering kernel configuration users with questions about. And isn't that a line in /proc//cgroup, not in /proc//status ? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
Thanks for doing this, Nick. One area looks like some details need working. Nick Andrew wrote: config PROC_PID_CPUSET bool Include legacy /proc/pid/cpuset file depends on CPUSETS default y + help + This option provides the legacy /proc/pid/cpuset file. + + It has been deprecated in favour of an additional line + in /proc/pid/status showing on which CPUs a process + may be scheduled. I don't think /proc/pid/cpuset (PROC_PID_CPUSET) is, or should be, deprecated. Actually, I'd be inclined toward removing this CONFIG option, and making /proc/pid/cpuset a non-optional consequence of enabling cpusets ... so I'm adding Paul Menage to the CC list, in case he has thoughts or insights on this. The duplication of this bit of information between both /proc/pid/cpuset and one line of /proc/pid/status is a minor and harmless wart, resulting from the evolution of cgroups from cpusets, that is not worth bothering kernel configuration users with questions about. And isn't that a line in /proc/pid/cgroup, not in /proc/pid/status ? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.940.382.4214 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Feb 19, 2008 7:12 AM, Nick Andrew [EMAIL PROTECTED] wrote: config CGROUPS bool Control Group support help - This option will let you use process cgroup subsystems - such as Cpusets + Control Groups enables processes to be tracked and grouped + into cgroups. This enables you, for example, to associate + cgroups with certain CPU sets using cpusets. - Say N if unsure. + When enabled, a new filesystem type cgroup is available + and can be mounted to control cpusets. How about: ... cpusets and other resource/behaviour controllers. Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Tue, Feb 19, 2008 at 06:04:57PM -0800, Paul Menage wrote: On Feb 19, 2008 7:12 AM, Nick Andrew [EMAIL PROTECTED] wrote: config CGROUPS [...] + When enabled, a new filesystem type cgroup is available + and can be mounted to control cpusets. How about: ... cpusets and other resource/behaviour controllers. Ok I added that. This is what I have now: config CGROUPS bool Control Group support help Control Groups enables processes to be tracked and grouped into cgroups. This enables you, for example, to associate cgroups with certain CPU sets using cpusets. When enabled, a new filesystem type cgroup is available and can be mounted to control cpusets and other resource/behaviour controllers. See file:Documentation/cgroups.txt for more information. If unsure, say N. I don't think that description is as clear as it could be. From the non-kernel-developer point of view, that is. I'll read Documentation/cgroups.txt more thoroughly and see if I can come up with a better description. Re other resource/behaviour controllers, what in particular? I take it that our current controllers are cpusets, scheduler, CPU accounting and Resource counters? Nick. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve init/Kconfig help descriptions [PATCH 6/9]
On Feb 19, 2008 6:54 PM, Nick Andrew [EMAIL PROTECTED] wrote: config CGROUPS bool Control Group support help Control Groups enables processes to be tracked and grouped into cgroups. This enables you, for example, to associate cgroups with certain CPU sets using cpusets. When enabled, a new filesystem type cgroup is available and can be mounted to control cpusets and other resource/behaviour controllers. See file:Documentation/cgroups.txt for more information. If unsure, say N. I don't think that description is as clear as it could be. From the non-kernel-developer point of view, that is. Originally this wasn't a user-selectable config value, it was auto-selected by any subsystem that needed it. I think that was nicer from the user-experience, and it would eliminate the need for this documentation but there were concerns that this triggered unspecified brokenness in the Kbuild system. Re other resource/behaviour controllers, what in particular? I take it that our current controllers are cpusets, scheduler, CPU accounting and Resource counters? Resource counters aren't a resource controller, they're a helper library. The others are good examples, as is the memory controller that's just been added to 2.6.25. Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
