> 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.
I do not know any application using timer values from /proc/net
but net-tools, so that all this subject looks shallow.
Look at your patch again and try to guess, what apps use these
timer values... one, two, three... I bet you did not remeber
anything but net-tools and, probably, procps, right?
> 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.
No, you understood me correctly. If some variable may jump
and application is not ready to it, it is just buggy.
If the variable was fixed for ages (as HZ), and then jumped
unexpectedly, you have to upgrade.
> (1) exporting the HZ value somewhere in /proc, and fixing all
> apps to use that for scaling
Yes. Only this "all" consists of couple of apps. 8)
At least, I set HZ to 1024 on Pentiums and never encountered any problems.
> (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.
It is correct, I see you did look at psched timers. 8)
With one correction: currently existing /proc/ nodes need no fixups.
New one should be clean, certainly.
> /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
Yes! It is absolutely correct. sysctl variables are measured
in seconds, when their value in jiffies is not important.
When they are measured in jiffies, they are measured in jiffies
and echo 1 means 1 jiffie.
> > 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.
8) Please, scan linux-kernel.
Timer values reported at least by /proc/net are suitable for debugging,
only for debugging and for nothing but debugging.
If you tried to teach someone to fetch timer of stuck TCP socket
with gdb to report bug, you would be of different opinion. 8)
> btw, did i get SCHED_JSCALE about right?
Yes. Though it would be better not to use bizarre HZ values,
1024 is good enough on modern machines and 100 for ancient ones.
Alexey
-
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/