lkml.org 
[lkml]   [2001]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] Re: UP APIC reenabling vs. cpu type detection o
On  8 Feb 01 at 6:04, Mikael Pettersson wrote:

> ordering and offsets in processor.h and head.S. The resulting
> kernel works ok on my UP P6.
> (Petr: can you check that it still works on your K7?)

I'll try.

I have another question for UP APIC NMI: As I reported some time ago,
if performance counters overflow when LVTPC has 'disabled' bit set,
NMI is lost forever. This causes problems with VMware - it has to
disable NMI deliveries during CR3 (memory mapping) switching, and if
performance counter overflows at that time, you'll not receive another
NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz
Athlon. And 410 * 65536 seconds on idle Athlon)...

So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
and if we receive even one NMI, we are locked up? It should increase
performance, as we'll do same number of MSR writes anyway (100/s), but
we will not receive any NMI during normal operation, so we save time
spent in processing this. Or do I miss something?

It may be problem on P6, as it has only 32bit perfctrs, so we are limited
to 4.1s watchdog timeout on 1GHz PIII :-(
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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