> > 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
Okay, gothca - I was using 'tunables' in a general sense, ie, any parameter which is tunable, whether that be by the system, or available directly to users through some well defined interface. > 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. This is an interesting concept, which allows dynamic 'automatic' adjustment, but also has the ability to expose an interface, *should* an expert user want to play around with the system. What would the 'daemon' want to know about, for example, to increase network throughput and processing? The daemon would be able to evaluate processes running, for example, and also note whether processes/threads within the kernel are getting huge amounts of device interrupts, or whether they are allocating huge amounts of buffer space, etc. The sheduler is excellent; scheduling is also becoming increasingly complex. Having a 'supervisor' would simply take some of the burden off the scheduler, for example, when deciding which processes should run. One example is network traffic. This form of activity generates large amounts of device interrupts (from the network interfaces) which puts a *huge* burden on both the system and the scheduler. Adaptation to massive network load would simply be to "place the core thread which handles network traffic onto the main CPU so that it lessens network latency and can handle the device interrupt and process the packet without having to wait until another TCP/IP thread is awoken on another processor to handle the request". The daemon would simply monitor this kind of behaviour and have specialised routines within it to handle specific situations independent of the kernel - it would simply influence the kernels behaviour without the kernel needing to really know about it. > discussion began). I would start by referring to > the discussions about > why /proc is bad choie. Maybe sysctl() is the I can understand that /proc is quite an elegant interface to the process subsystem and that the kernel engineers would not like to introduce fudges into the system. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
