Re: Measured overhead of timer interrupts

Khimenko Victor (khim@sch57.msk.ru)
Thu, 22 Jul 1999 18:07:24 +0400 (MSD)

In <199907221321.PAA03179@cave.BitWizard.nl> Rogier Wolff (R.E.Wolff@BitWizard.nl) wrote:
> kuznet@ms2.inr.ac.ru wrote:
>> > 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.

> I hope I misunderstood you.

> HZ is not only exported through /proc . It is an external interface,
> which applications can depend on. No matter what. They can depend on
> "read" reading in a piece from a file, they can expect "sleep (1)" to
> last a second, and they can expect HZ to be the value it was when the
> application was compiled.

If you can show me any POSIX standard where HZ is mentioned along with
such requirement then yes, otherwise -- no.

> This also goes for commercial applications where joe random user
> doesn't have the source for.

In such case you should ask vendor for upgrade.

-
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/