Messages in this thread | | | Date | Thu, 22 Jul 1999 20:56:25 +0200 | From | Artur Skawina <> | Subject | Re: Measured overhead of timer interrupts |
| |
kuznet@ms2.inr.ac.ru wrote: > > > I see your point. The problem is that the /proc files are an > > exported interface; nettools isn't the only thing that uses > > 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?
you lost :) (think tools that examine socket state and timers to make decisions whether to setup/tear down a link. Guess why i immediately noticed the broken /proc timers... :^) )
> > 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.
Where was/is HZ defined as variable (on a given architecture)? There are however a lot of places that document/assume a constant HZ. Why would an application assume HZ, as presented to it, could ever change when HZ was and still is not even exported to userspace properly? Just how do you expect applications to "be ready" for a numeric value being 2048 instead of 200 - detect and handle it properly, when you are not telling it the unit?
> If the variable was fixed for ages (as HZ), and then jumped > unexpectedly, you have to upgrade.
if you start changing well known constants, and not even provide a way to detect legacy application which are affected I'm afraid upgrading applications is not what the solution would be...
> > (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)
Which you happen to know of. Other than the inhouse custom apps in use, there are then also any (commercial or otherwise) closed source apps - do you really expect everybody to trace those just to make sure they are not depending on the timer values?
> At least, I set HZ to 1024 on Pentiums and never encountered any problems.
I got bitten within minutes...
> > (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)
Actually, I have no idea what you're talking about :) The above scheme is what I would like to have for some of my applications, and what I think would be generic enough for all possible use, that's all.
> With one correction: currently existing /proc/ nodes need no fixups. > New one should be clean, certainly.
unfortunately existing /proc files cannot be fixed properly. If I'm going to "fix" applications I would rather do it once, using _new_ proc nodes, anyway.
> > '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.
Things get more complicated when you can have more than one HZ value... (something like andi's suggestion (picking the largest HZ) might be an acceptable solution) [I not sure I like the idea of conditionalizing the startup scripts for different HZ :) ]
> > 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.
I _currently_ _use_ them, you may argue that was not their purpose, but what do you suggest instead?
> 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)
that was just one of the solutions, and why i said there could be problems ;) new /proc files with raw data would solve the problem. if you design them right they could be used instead of the old ones (in "upgraded"/new apps) and the whole problem would be solved once and for all. There aren't that many proc nodes involved...
> Yes. Though it would be better not to use bizarre HZ values, > 1024 is good enough on modern machines and 100 for ancient ones.
I currently support 100,200,400,800,1024 for ia32 (mostly so that the scaling is as lossless as possible).
How about changing the ipv6 nodes to report the values using some, documented, constant unit? I don't believe there are many things that depend on these values yet so at least this coould be fixed now...
Couldn't the ((s32)(tcp_time_stamp - tp->ts_recent_stamp) >= PAWS_24DAYS) check use a bit scaled down values so it works with HZ>1024 on 32 bit platforms?
artur
- 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/
| |