Messages in this thread | | | From | "Khimenko Victor" <> | Date | Fri, 23 Jul 1999 04:58:35 +0400 (MSD) | Subject | Re: Measured overhead of timer interrupts |
| |
In <19990723003639.B3385@fred.muc.de> Andi Kleen (ak@muc.de) wrote: AK> On Thu, Jul 22, 1999 at 09:12:22PM +0200, Khimenko Victor wrote: >> In <19990722171109.A1783@fred.muc.de> Andi Kleen (ak@muc.de) wrote: >> > On Thu, Jul 22, 1999 at 05:02:14PM +0200, Ingo Molnar wrote: >> >> >> >> On 22 Jul 1999, Andi Kleen wrote: >> >> >> >> > It is a kernel bug, HZ is not exported. Actually two, because none of >> >> > the /proc should have used it as units, but that cannot be fixed anymore. >> >> >> >> why cannot it be fixed? >> >> > because that would break the interface. >> >> /proc interface are in permanent change. We should keep it consistent in one >> stable kernel series but I see no reason to keep it consistent between major >> kernel updates: quite a lot of things will be changed anyway.
AK> This is not really true. There are new columns or lines added to /proc AK> files, but old ones are not changes, and correctly writen /proc parsers AK> should not break (unfortunately there are lots of incorrectly writen AK> proc parser around..)
I yet to see "correct parser" with ability to find out file-max, file-nr, inode-max and inode0-nr moved from /proc/sys/kernel in 2.0 to /proc/sys/fs in 2.2...
>> >> > It is easy to add a read-only sysctl for HZ though and make netstat use >> >> > this, but this won't fix the trillions of other /proc parsers. >> >> >> >> we do not want to export HZ, why should we? HZ has no meaning to anything >> >> else than the kernel. If the kernel exports HZ-dependent values into >> >> /proc, then that has to be fixed. (yes it might be painful in some cases) >> >> HZ might even go away in future kernels - what if we start using >> >> nonperiodic timer interrupts? >> >> > Actually, POSIX wants it (sysconf(_SC_CLK_TCK)). glibc currently returns >> > the HZ value it was compiled with, but that is hardly satisfying. >> >> This means that GLiBC must be fixed...
AK> First the kernel needs to export the necessary information. glibc is AK> hardly to blame here.
Of course. It's two step procedure :-) I do not blame GLibC here, I describe what must be done...
>> > I agree that the time related sysctls/proc files should be fixed, but I'm >> > afraid it is too late. >> >> /proc files are not a problem but sysctls... In which sysctls HZ is used in >> such way that GLibC recompilation will not help ?
AK> It has nothing to do with glibc. There are documented sysctls that use AK> HZ as unit, and Linux has long ago left the innocent state where you AK> can change documented interfaces without thinking and some migration AK> strategy.
When it "left the innocent state" ??? I always was sure that there are is well-defined migration strategy: broke things in experimental branch and make sure all needed programs will be updated...
Concerning HZ: what are those sysctls ? How many programs use them ?
- 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/
| |