[LAU] More recent kernel config options

[Brent Busby]

In addition to the question I posted earlier about PREEMPT_RCU, I've 
found still other kernel config options that are not covered in most of 
the extant howtos for setting up low latency kernels, because they are 
recently added in the unpatched kernel.  (Or at least, they're more 
recent than most of the howtos...)

I've been researching these options, mostly by googling (and 
googling...and googling) the Linux Kernel Mailing List archives, and 
also by looking at the config used by 64Studio, since it seems the 
prevalent opinion is that they are stable as a rock.  With the latter 
approach of checking against 64Studio's config, I've had little luck 
though, because their distro currently comes in a 2.1 "stable" version 
that is based on Debian "etch", with a 2.6.21 kernel that predates the 
existence of some of the config options I'm asking about; and a 3.0 
"beta" version that uses a newer kernel, but should also probably be 
taken with a grain of salt, because 64Studio is still working the bugs 
out of it, and because it seems to have options turned on that the LKML 
archives have warned strongly against.  So, most of the information I've 
gleaned has been from the LKML.

I might as well collate these questions here, for what good it may do. 
The kernel I'm configuring is 2.6.29.6 with matching RT patches (-rt23), 
though all of the options listed here are actually present even in the 
unpatched 2.6.29.6 kernel.



PREEMPT_RCU :

This was the one my original question was about in the earlier post. 
In the newer kernels (even mainline ones, without any RT patches), there 
is a choice of "RCU Subsystem", with one option being "classic", and 
other being "preemptable".  The choice would seem obvious for low 
latency, except that the help text warns that a preemptible RCU is 
likely to expose serious kernel bugs that may render the system 
completely unstable.  (This is *not* the same setting as the various 
CONFIG_PREEMPT options that have been present in the mainline kernel for 
awhile now.  This is something new, and it appears in menuconfig as a 
separate setting.)  I think I've mostly gathered from reading through 
the whole process of debugging that the kernel gurus went through that 
as of last year or so, this is now considered mostly stable, after 
having been subjected to a utility called 'rcutorture', and having fixed 
many lockups.  I'd still be interested in anything anyone else can 
contribute about it though, especially if they're using it and they 
also think it is stable.


GROUP_SCHED :

This one is interesting, and I don't know what to make of it, other than 
that the LKML seems to have decided in the last two months or so that it 
slows your system down and makes latencies worse.
 	The thing that's confusing about it though is that it's 
described as a mechanism for grouping high priority tasks by group. 
It's implied (though not spelled out specifically) that they even mean 
by this Posix groups, because in one document I read, it says that 
enabling this will cause you to be unable to get realtime as a non-root 
user unless you are setup in a group specified in limits.conf.  Hmm! 
That sounds an awful lot like what we've just been calling pam_limits 
for years now.  Are we doing this with a kernel config option now?  (One 
which apparently doesn't work?)
 	The 3.0 (beta) version of 64Studio turns this on.  Then again, 
looking at their kernel config, they seem to turn everything on, and 
that might be why it's considered beta.  (The 2.1 stable version of 
64Studio seems to have a kernel old enough that it never had that 
option as a choice.)  Anyone have any feedback about this?  It's only in 
the past two months that the kernel gurus have decided that it's bad, 
but they're actually considering marking it broken from what I've read.


CGROUPS :

This sounds cool, but I'm reasonably sure it's not actually necessary. 
Documentation I've read suggests that this allows for letting 
applications (or users) define CPU and memory pool affinity for tasks, 
so that one could arbitrarily tie down particular threads or tasks to a 
given processor core, or region of memory (or something like that). 
However, the thing that makes me somewhat sure I don't positively need 
this is that the same documentation also says that if you want to use 
it, you need to create a new subdirectory under /dev, mount a new 
pseudofilesystem under it, and then this module will populate that space 
with dynamic configuration data about these affinity groups for running 
tasks.  I have neither seen any distro (even ones made for musicians) 
that has set any such thing up out of the box, nor have I ever seen a 
realtime howto that tells people to do it themselves.  It sounds like 
there's a lot of infrastructure necessary for this that's not common in 
distros yet.  (Though I see that regular Debian "lenny" turns this on in 
the kernel without actually providing the special /dev support for it, 
which I presume they're thinking you'll setup yourself if you're 
interested.)  Still, comments welcome...


-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ UNIX Systems Admin	 +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
+ James Franck Institute +  we know this is not true." -Robert Wilensky