Messages in this thread | | | Date | Wed, 19 Jul 2000 11:46:51 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: D-Link DFE-570TX: driver issues w/ tulip and de4x5 |
| |
On Wed, 19 Jul 2000, Anton Ivanov wrote: [Snipped...] > > > The F00F maybe? Bug inside? > And just a quick long standing wishlist I keep forgetting to post: > There are cases when this check may and actually for performance > reasons must > be happily killed, disabled, whatever. The only way to do so last time I > looked was to comment the code out. Having this as a compile option is much > cleaner. >
The F00F bug-fix has no affect on performance. The only way it will affect performance is if you have defined a special handler for illegal opcodes and insist upon putting them into your executable code.
The bug-fix works by making (marking) the illegal-opcode interrupt descriptor "not-present". Therefore, if you execute an illegal op-code, the descriptor has to be paged in. This allows the page-fault handler to inspect the code. This paging only occurs when an undefined op-code exists in the instruction stream.
Note that 32-bit mode uses interrupt/trap gates, defined by descriptors. These descriptors can exist anywhere in physical RAM. They don't have to be "in order" like an interrupt table. Therefore, the descriptor for the illegal-opcode trap descriptor (only) is put in a page that is marked not-present.
This does waste the rest of the page (RAM), however it does not affect performance.
Cheers, Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
- 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/
| |