lkml.org 
[lkml]   [1999]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.073 / U:3.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site