On Tue, Jul 12, 2005 at 05:38:51PM -0700, Random wrote: > Eliminating tuneables is a *silly* thing to do, even if the process of tuning > is 'automatic'. As OS kernels and the systems they control become *far* more > complex, giving the system access to dynamic tuning is a *good* thing to do. > Systems undergo dynamic usage - at one point during the day, network load > might be far more intense than at others, and the process load also > fluctuates. > > Even if the parameters are accessible to a 'daemon' like process which > monitors the various subsystems, and updates the system dynamically through > some kind of clean interface, be that /proc or sysctl (), or some other > method. Even going to the extreme of allocating specific processors to the > task of network processing, for example, when network load is *extremely* > high.
It seems like you're agreeing with what everyone else just said. AFAICT, you're saying that dynamic tuning (in this case reacting to network load) is the way of the future, in which case we're in total agreement - tunables are evil. Obviously, there are variables which change value within the kernel and affect the behavior of the system. But this does not make them a "tunable". A tunable is a public, documented, interface to affect the behavior of the system. If there's a private tunenetworkload() system call that some daemon uses, then this is exactly the interface we're hoping to design. Maybe it goes and twiddles a dozen different parameters in the kernel, but the point is that the kernel parameters are never exposed. Instead, we focus on the high level utility (the network load daemon) as the primary interface, which hopefully has no interface at all. If you want to discuss the programmatic method by which private variables are set, this is a different topic (although one in which this discussion began). I would start by referring to the discussions about why /proc is bad choie. Maybe sysctl() is the "right" interface, but that doesn't mean that there should be a sysctl(2) manpage declaring them public tunables that every admin should learn to tweak appropriately. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
