kernel for p4 (kinda OT)
Anyone have some ideas why they never built an arch for p4 CPUs into the kernel? I realize that these are covered by i386. A little while ago, after looking round a bit in a custom tree and creating a p4 arch myself (Im not a programmer BTW, just hacking, pruned out some 'surplus' code mostly, using 2.6.14), a clean build ran in *lots* less time. No runtime benchmarks, but response times were also definately better, and had no issues with drivers or anything. Used gcc 3.4.5 too. It wasnt quite as stable so I did something wrong somewhere, but it seems odd there was no real demand for this arch. Especially since p4s have been around for so long. BTW I did have a look on google, but mostly found newbies asking the same question with no response or devs saying they couldnt be bothered lol. Just seems a shame to waste potential if its there :). Comments? -- No outsider has ever seen a Tleilaxu female and lived to tell about it. Considering the Tleilaxu penchant for genetic manipulation -- see, e.g., related memos on clones and gholas -- this simple observation raises a wealth of additional questions. -- Bene Gesserit Analysis
On Fri, Mar 24, 2006 at 01:59:34AM +1200, Glenn Enright wrote:
Anyone have some ideas why they never built an arch for p4 CPUs into the kernel? I realize that these are covered by i386. A little while ago, after looking round a bit in a custom tree and creating a p4 arch myself (Im not a programmer BTW, just hacking, pruned out some 'surplus' code mostly, using 2.6.14), a clean build ran in *lots* less time.
my 2.6.11 source tree has the option to target p4's: make menuconfig "Processor type and features" -> "Processor family" -> ┌───────────────────────── Processor family ─────────────────────────┐ │ Use the arrow keys to navigate this window or press the hotkey of │ │ the item you wish to select followed by the <SPACE BAR>. Press │ │ <?> for additional information about this option. │ │ ┌──────────^(-)──────────────────────────────────────────────────┐ │ │ │ ( ) Pentium-II/Celeron(pre-Coppermine) │ │ │ │ ( ) Pentium-III/Celeron(Coppermine)/Pentium-III Xeon │ │ │ │ (X) Pentium M │ │ │ │ ( ) Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon │ │ │ │ ( ) K6/K6-II/K6-III │ │ │ │ ( ) Athlon/Duron/K7 │ │ │ └──────────v(+)──────────────────────────────────────────────────┘ │ ├────────────────────────────────────────────────────────────────────┤ │ <Select> < Help > │ └────────────────────────────────────────────────────────────────────┘
On Thursday 23 March 2006 14:04, John R. McPherson wrote:
On Fri, Mar 24, 2006 at 01:59:34AM +1200, Glenn Enright wrote:
Anyone have some ideas why they never built an arch for p4 CPUs into the kernel? I realize that these are covered by i386. A little while ago, after looking round a bit in a custom tree and creating a p4 arch myself (Im not a programmer BTW, just hacking, pruned out some 'surplus' code mostly, using 2.6.14), a clean build ran in *lots* less time.
my 2.6.11 source tree has the option to target p4's:
Yes but the core of the kernel builds on the same code as used for most other intel chips. look at /usr/src/linux/arch/* for i386. Also all include files used are in /usr/src/linux/include/asm-i386. The main difference by using that selection is that the compiler builds in some optimisations that apply the that arch, via the Makefiles. The same source code is traversed, and one of the difficulties of having such general code is that it can bloat the builds a bit, simply through build overhead. Its easy to see that many efforts have been made to limit this effect through ifdef structures and such. -- Princess Leia Organa: Help me, Obi-wan Kenobi. You're my only hope.
Yes but the core of the kernel builds on the same code as used for most other intel chips. look at /usr/src/linux/arch/* for i386. Also all include files used are in /usr/src/linux/include/asm-i386. The main difference by using that selection is that the compiler builds in some optimisations that apply the that arch, via the Makefiles. The same source code is traversed, and one of the difficulties of having such general code is that it can bloat the builds a bit, simply through build overhead. Its easy to see that many efforts have been made to limit this effect through ifdef structures and such.
Well I think it is a moot point now anyway as most people will be focussing on AMD64 now anyway if they are developers... -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
On Thursday 23 March 2006 14:26, Ian McDonald wrote:
Well I think it is a moot point now anyway as most people will be focussing on AMD64 now anyway if they are developers...
Not surprising I guess. Only so much focus to go round :) -- "One word sums up probably the responsibility of any governor, and that one word is 'to be prepared'." George W. Bush December 6, 1993
participants (3)
-
Glenn Enright -
Ian McDonald -
John R. McPherson