linux-kernel - Re: [PATCH] I/O APIC: Timer through 8259A revamp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 20 May 2008 00:34:19 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] I/O APIC: Timer through 8259A revamp

Maciej W. Rozycki wrote:
> On Mon, 19 May 2008, Andi Kleen wrote:
> 
>>>  With the ACPI tables, hardware is modern enough the timer interrupt 
>>> should be directly available, but is usually wired in the way recommended 
>>> by the MP spec.
>> I originally had that assumption too, but in practice that doesn't seem
>> to be always the case unfortunately. Or sometimes the tests just fail
>> for whatever reason and they drop into the fallback path.
> 
>  Well, the fallback path was meant to be used with hardware suffering from
> limitations and not from broken configuration tables. 

I don't think it was wrong tables generally, but more screwy hardware.

The main table problem were with nvidia with the wrong timer overrides,
but that was handled elsewhere. And a long time ago ACPI couldn't handle
the VIA interrupt configuration properly, but that was also fixed later.

>> On the other hand with wider use of tickless kernels and hrtimers it might 
>> be tolerable to use non standard HZ,
> 
>  I don't think the value of HZ should be a problem anymore now that we
> have a separate user-visible HZ 

I wasn't worried about the units in sysctl, but about the minimum delay
time in select() and other timeout syscalls. And yes changing that
changes user behaviour significantly. And it's still HZ granuality.
I don't think anybody dared to change it to hrtimers yet because it has
potentially large impact on applications.

Of course you could probably define a "true user hz" that is emulated
with hrtimers even when the system tick is different. Problem is also
that a lot of systems don't support hrtimers yet because they have both
broken APIC timer and missing HPET.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/