Messages in this thread | | | Date | Wed, 21 Jul 1999 19:30:41 +0200 | From | Artur Skawina <> | Subject | Re: Measured overhead of timer interrupts |
| |
kuznet@ms2.inr.ac.ru wrote: > > > The networking stuff in particular needs fixing, otherwise > > the timer values displayed eg by netstat look 'interesting'. > > Fix netstat, please, rather than kernel.
I see your point. The problem is that the /proc files are an exported interface; nettools isn't the only thing that uses that information.
> > If anybody wants to try a higher HZ then something like the > > attached patch should be enough. But it probably still misses > > a few things (suggestions welcome). > > Scaling times is not kernel problem.
Ideally the kernel should export both the values and necessary unit/granularity info and then the apps could do the scaling properly - yes. Unfortunately until now it hasn't been doing that, so apps had to assume a known const HZ. It's about backwards compatibility.
> Tools parsing proc contains so much of dependencies, that > it is meaningless to help them.
hmm, i'm not sure how to interpret this - it sounds to me much like:
We don't care about any apps that use the info exported through /proc. All applications must be prepared to deal with numeric values suddenly changing by an order of magnitude after a kernel reconfiguration/upgrade. We will do nothing to even try to help them detect this change.
I hope i misundertood you.
In the HZ case there certainly are a few options that could be done:
(1) exporting the HZ value somewhere in /proc, and fixing all apps to use that for scaling
(2) using the existing convention HZ==100 for existing proc files; exposing raw values via other means (eg for debugging)
(3) like (2), but making the new i/f generic enough (ie use raw values, but also export the units and granularity information (eg a value can be in ms, but only have a resolution of 4ms so both would be needed)); documenting it, declaring the old files obsolete, fixing all apps to use the new scheme.
/Fix netstat, not kernel/ means (1), right? The problem with that is that the silent change breaks existing tools (i'm not talking about nettools, but any app that makes decisions based on some /proc value) in a way that's not acceptable (if it would have caused them to fail it would be more acceptable, but giving them bogus information silently isn't). (1) also means that an "echo '100' >/proc/whatever" suddenly can mean something very different (this btw is also true for /proc/sys/vm/*). (2) lets you use existing tools, and doesn't prevent doing the right thing in the future.
> For debugging I want to see variables EXACTLY as they > look to kernel. The fact that timer value = 1 jiffie > is critical information.
yes. for development this can be obtained by other means (like another proc file with raw data / /dev/mem / kernel debugger). for gathering data from production boxes, masquerading this data could be a problem.
btw, did i get SCHED_JSCALE about right?
artur
PS. I probably shouldn't even mention nfs exported /proc. :^)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |