login
Header Space

 
 

Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Rene Herman <rene.herman@...>
Cc: Paul Rolland <rol@...>, H. Peter Anvin <hpa@...>, Krzysztof Halasa <khc@...>, Pavel Machek <pavel@...>, Andi Kleen <andi@...>, Alan Cox <alan@...>, David P. Reed <dpreed@...>, <linux-kernel@...>, Thomas Gleixner <tglx@...>, Ingo Molnar <mingo@...>, <rol@...>
Date: Tuesday, December 11, 2007 - 9:50 am

Rene Herman wrote:

That could be true if outb_p were used only in architecture dependent 
code, but it's not.  It's used in drivers that are supposed to run on 
all sorts of platforms.  Why does a megaraid controller need delays on 
i386 but not on Sparc, PowerPC, Alpha and others?  Is it buggy on most 
platforms, or just unnecessarily slow on Intel?


You misunderstand.  A delay can be counted in bus cycles.


It's most commonly a zero delay.  Only in the minority of architectures 
is it otherwise.  If a delay is needed, then put one in, but don't put 
in a paper promise that's more likely to be ignored than observed.

Plenty of doubt has been expressed as to whether _p is widely used 
without need.  Not surprising since it has such a vague specific 
meaning.  One could say, Linux on i386 is liberally sprinkled with 
needless delays.  I suppose it has the advantage that Microsoft will be 
hard pressed to catch up when finally we remove them. :-)

I really prefer accurate code, but I'm also pragmatic and realise that 
it's far too much work to fix this any time soon.  But if it were to be 
fixed, then perhaps _p would take an additional parameter, measured in 
cycles of delay.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., David Newall, (Tue Dec 11, 9:50 am)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Tue Dec 11, 11:41 am)
More info on port 80 symptoms on MCP51 machine., David P. Reed, (Wed Dec 12, 4:07 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Wed Dec 12, 4:26 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Wed Dec 12, 4:58 pm)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Wed Dec 12, 5:05 pm)
Re: More info on port 80 symptoms on MCP51 machine., Chuck Ebbert, (Fri Dec 14, 6:05 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Sat Dec 15, 3:22 am)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Wed Dec 12, 5:12 pm)
RE: More info on port 80 symptoms on MCP51 machine., Allen Martin, (Sat Dec 15, 6:34 pm)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Sat Dec 15, 6:46 pm)
Re: More info on port 80 symptoms on MCP51 machine., David P. Reed, (Wed Dec 12, 4:37 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Tue Dec 11, 4:27 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Wed Dec 12, 9:11 am)
Attitude problems., David P. Reed, (Wed Dec 12, 3:42 pm)
Re: Attitude problems., linux-os (Dick Johnson), (Wed Dec 12, 4:31 pm)
Re: Attitude problems., linux-os (Dick Johnson), (Fri Dec 14, 12:01 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., Dr. David Alan Gilbert, (Sun Dec 9, 9:41 am)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., Lennart Sorensen, (Tue Dec 11, 11:14 am)
speck-geostationary