Messages in this thread | | | Date | Sun, 8 Mar 1998 22:52:34 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: [PATCH] Cyrix setup |
| |
On Sun, 8 Mar 1998, Phil Brutsche wrote:
> > Here we go for a new Cyrix patch. > > Indeed, many Cyrix users use the K.Gadeyne's set6x86 program with a simple > > rc script in order to enable several 6x86 features at bootup. So why not > > just merging these initializations in the kernel ? > Ah... sorry, but no. What would happen if someone would use some of > those performace-enhancing options in the intitialization of the kernel? > Either: > a) They would work great and the kernel would be super fast > or > b) They wouldn't work at all and would completely mess things up (lock > the machine, interfere with HD operation, I can't recall what the points > where against doing this during the last discussion). > > Besides, what if someone wanted to CHANGE those options? They would have > to re-compile their kernel every time. It's so much more convenient to > have the initializations in a user-space program.
maybe a (non /proc :) filesystem (possibly demand-loadable as a module) could provide all the flexibility, still it could do things like SMP-safe setting of CPU features, cache flushes and other, 'best done in the kernel' stuff. All the nice performance-things like MTRR's, cache settings and pipeline stategies and other uses [like the Cyrix performance features] could be accessed in a consistent way. It could thus serve as a central collection of CPU-related low-level performance hacks?
one could do:
echo 1 > /cpu/cache/L2/writeback echo 1 > /cpu/pipeline/fast_IO
some of /proc could be moved to /cpu. Wether all these CPU features can be represented properly in human-readable form via a VFS interface, tough question.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |