Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Ihar 'Philips' Filipau]

Michael Rozhavsky wrote:
>>Considered the time normally spent in the kernel, a few percent faster
>>code there wouldn't be noticeable.
> 
> What about firewall/router applications?
> 

   First. Network stack is already hand-optimized.
   Second. It will not make software firewall/routers running faster - 
especially regarding latencies - bottleneck is elsewhere.

   Just FYI.

P.S. Actually I find Linux kernel being quite good hand optimized 
already. But in any way, life in kernel would be made easier have we 
decent portable compiler. But as to compilers 'decent portable' really 
sounds like 'mission imposible'. And primary goal of gcc sure standard 
conformance and portability - and it does this well. That's actually why
we are using it ;-)

  -- Person using gcc on Linux 2.4 x86/ppc32 & Solaris 8/9 with no 
problems at all.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Ihar 'Philips' Filipau]

Michael Rozhavsky wrote:
>>Considered the time normally spent in the kernel, a few percent faster
>>code there wouldn't be noticeable.
> 
> What about firewall/router applications?
> 

   First. Network stack is already hand-optimized.
   Second. It will not make software firewall/routers running faster - 
especially regarding latencies - bottleneck is elsewhere.

   Just FYI.

P.S. Actually I find Linux kernel being quite good hand optimized 
already. But in any way, life in kernel would be made easier have we 
decent portable compiler. But as to compilers 'decent portable' really 
sounds like 'mission imposible'. And primary goal of gcc sure standard 
conformance and portability - and it does this well. That's actually why
we are using it ;-)

  -- Person using gcc on Linux 2.4 x86/ppc32 & Solaris 8/9 with no 
problems at all.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--
   "... and for $64000 question, could you get yourself vaguely
      familiar with the notion of on-topic posting?"
				-- Al Viro @ LKML

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Andi Kleen]

"J.A. Magallon" <jamagallon@able.es> writes:

> Patch inlined. Credits should go to Zwane Mwaikambo <zwane@linux.realnet.co.sz>.
> It adds the corresponding flags for PII) and P4, and in case thei are defined,
> the *fence insn are used.
>
> Included is also one other patch by Zwane, which states that smp_call_function
> needs mb() instead of wmb().
>
> I use them regularly, so they look safe. Are they really better ? At least they
> do not touch any register, like the trick used till now.

The current code also does not touch any register. It has a gcc memory
barrier, which is costly, but needed.

The wmb() change is not needed, unless you have an oostore CPU
(x86 has ordered writes by default). It probably does not hurt
neither though (I do it the same way on x86-64), but also doesn't 
change anything.

I think overall the patch is a very bad idea because it adds weird CPU
dependencies to the image again for very little again If you really
want to do this use alternative() and runtime patching. But it's
probably not worth the effort - don't do it until you can demonstrate
a difference in any benchmark.

-Andi

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Zwane Mwaikambo]

On Mon, 27 Oct 2003, Andi Kleen wrote:

> The wmb() change is not needed, unless you have an oostore CPU
> (x86 has ordered writes by default). It probably does not hurt
> neither though (I do it the same way on x86-64), but also doesn't 
> change anything.

The original intent was to fix an SMP P5 system, it oopses otherwise under 
load.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Andi Kleen]

Zwane Mwaikambo <zwane@arm.linux.org.uk> writes:

> On Mon, 27 Oct 2003, Andi Kleen wrote:
> 
> > The wmb() change is not needed, unless you have an oostore CPU
> > (x86 has ordered writes by default). It probably does not hurt
> > neither though (I do it the same way on x86-64), but also doesn't 
> > change anything.
> 
> The original intent was to fix an SMP P5 system, it oopses otherwise under 
> load.

That doesn't make any sense. P5 doesn't support SFENCE.

-Andi

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Zwane Mwaikambo]

On Mon, 27 Oct 2003, Andi Kleen wrote:

> Zwane Mwaikambo <zwane@arm.linux.org.uk> writes:
> 
> > On Mon, 27 Oct 2003, Andi Kleen wrote:
> > 
> > > The wmb() change is not needed, unless you have an oostore CPU
> > > (x86 has ordered writes by default). It probably does not hurt
> > > neither though (I do it the same way on x86-64), but also doesn't 
> > > change anything.
> > 
> > The original intent was to fix an SMP P5 system, it oopses otherwise under 
> > load.
> 
> That doesn't make any sense. P5 doesn't support SFENCE.

I think i misparsed what you were referring to, i thought it was the patch 
with the barrier in smp_call_function().

My bad.

FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under 
processor type when doing a 'make xconfig', but those selections do not 
translate into the appropriate -mcpu and -march flags.

While the kernel on x86 architecture can be optimized in terms of generic 
processor specifications (i.e. i386, i486, i586, i686), the kernel can't be 
optimized beyond a i686.

If you select Pentium III, the -march flag is set to i686.
If you select Pentium 4, the -march flag is set to i686.
If you select Athlon 4, the -march flag is set to i686.
If you select Athlon XP, the -march flag is set to i686.

It should be that...

If you select Pentium III, the -march flag is set to pentium3.
If you select Pentium 4, the -march flag is set to pentium4.
If you select Athlon 4, the -march flag is set to athlon-4.
If you select Athlon XP, the -march flag is set to athlon-xp.

I don't want to have to hand edit the makefiles just to optimize my kernel.  
I think this change is simple enough to do, and would allow kernel 
developers the option of processor-specific optimizations in the future.

TIA.

Joseph D. Wagner

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Måns Rullgård]

"Joseph D. Wagner" <theman@josephdwagner.info> writes:

> Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under 
> processor type when doing a 'make xconfig', but those selections do not 
> translate into the appropriate -mcpu and -march flags.

In Linux 2.6.0-test8, the flags are correct.  Which version are you
referring to?

> I don't want to have to hand edit the makefiles just to optimize my kernel.  
> I think this change is simple enough to do, and would allow kernel 
> developers the option of processor-specific optimizations in the future.

Considered the time normally spent in the kernel, a few percent faster
code there wouldn't be noticeable.

-- 
Måns Rullgård
mru@kth.se

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

> In Linux 2.6.0-test8, the flags are correct.  Which version are you
> referring to?

2.4.22

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Michael Rozhavsky]

> Considered the time normally spent in the kernel, a few percent faster
> code there wouldn't be noticeable.

What about firewall/router applications?

> 
> -- 
> M?ns Rullg?rd
> mru@kth.se
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
     Michael Rozhavsky

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Dave Jones]

On Wed, Oct 22, 2003 at 06:55:15PM +0600, Joseph D. Wagner wrote:

 > If you select Pentium III, the -march flag is set to pentium3.
 > If you select Pentium 4, the -march flag is set to pentium4.

Already done for 2.6

 > If you select Athlon 4, the -march flag is set to athlon-4.
 > If you select Athlon XP, the -march flag is set to athlon-xp.

Last time I looked these made absolutely no difference to performance
due to the only differences being on FP code.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

> Already done for 2.6

Version 2.6 is still in beta.  Besides, this should have been done years ago 
before 2.6 existed.

> Last time I looked these made absolutely no difference to performance
> due to the only differences being on FP code.

So what?  Some other kernel developer -- like a module/driver developer, a 
real-time systems developer, a simulations developer, or just some guy 
messing around (read: student) -- might really want or even need those 
specific optimizations.

Isn't this whole free-as-in-freedom software thing about giving developers 
and end-users options they wouldn't otherwise have under closed source 
alternatives?  In that spirit, shouldn't developers have the option of 
optimizing for those specific processors?

And don't give me this crap that being open source means I can do it myself.  
The fact is that most people can't make the changes themselves.  Then, 
instead of chosing between an operating system they like and an operating 
system they hate, people end up choosing between an operating system they 
hate and an operating system they really hate.

This is one of the reasons why I've never contributed to any open source 
project: the my-way-or-the-highway attitude of the existing developer base 
makes attempts for newbies to get inside an invintation for unnecessary 
pain.

Unless there's some hidden section of makefile code I don't know about, you 
can count the number of lines that would have to be changed to meet my 
request on the fingers of one of your hands.  If you don't make the change, 
I will consider it conclusive proof that the whole free-as-in-freedom is 
really just free-as-in-beer.

Joseph D. Wagner

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Rik van Riel]

On Wed, 22 Oct 2003, Joseph D. Wagner wrote:

> Version 2.6 is still in beta.  Besides, this should have been done years
> ago before 2.6 existed.

So why haven't you done it?

*sheesh*

Lazy people ...

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

RE: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

> > Version 2.6 is still in beta.  Besides, this should have been done years
> > ago before 2.6 existed.
> 
> So why haven't you done it?

Um... because I don't have cvs WRITE access.

*sheesh*

Stupid people ...

RE: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Rik van Riel]

On Wed, 22 Oct 2003, Joseph D. Wagner wrote:

> > > Version 2.6 is still in beta.  Besides, this should have been done years
> > > ago before 2.6 existed.
> > 
> > So why haven't you done it?
> 
> Um... because I don't have cvs WRITE access.

Nobody has.  That is not the way Linux development is done.

> *sheesh*
> 
> Stupid people ...

They could be everywhere, possibly even between your
keyboard and chair.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Wed, 2003-10-22 20:14:30 -0500, Joseph D. Wagner <theman@josephdwagner.info>
wrote in message <000801c39903$034d3910$0201a8c0@joe>:
> > > Version 2.6 is still in beta.  Besides, this should have been done years
> > > ago before 2.6 existed.
> > 
> > So why haven't you done it?
> 
> Um... because I don't have cvs WRITE access.

Nearly onbody has. However, you can download the latest kernel source
tarball, do your hacks and send us a patch to LKML. Then, you'll
possibly get some comments (better change this to do that, some
potential to do things better, ...). Send it again, until it's quite
good. Then, send it to Linus (or to the guy that's maintaining the part
you've changed) and LKML until it gets accepted.

That's the way it works.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Måns Rullgård]

"Joseph D. Wagner" <theman@josephdwagner.info> writes:

>> > Version 2.6 is still in beta.  Besides, this should have been done years
>> > ago before 2.6 existed.
>> 
>> So why haven't you done it?
>
> Um... because I don't have cvs WRITE access.

Of course not.  The Linux source uses BitKeeper.

-- 
Måns Rullgård
mru@kth.se

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Tim Hockin]

On Wed, Oct 22, 2003 at 07:47:45PM +0600, Joseph D. Wagner wrote:
> > Last time I looked these made absolutely no difference to performance
> > due to the only differences being on FP code.
> 
> So what?  Some other kernel developer -- like a module/driver developer, a 
> real-time systems developer, a simulations developer, or just some guy 
> messing around (read: student) -- might really want or even need those 
> specific optimizations.

Justify how someone NEEDs something that does nothing?

> Isn't this whole free-as-in-freedom software thing about giving developers 
> and end-users options they wouldn't otherwise have under closed source 
> alternatives?  In that spirit, shouldn't developers have the option of 
> optimizing for those specific processors?

They do - it's easy enough to hack in.  Go for it.  

> And don't give me this crap that being open source means I can do it myself.  

Ahh, grumpy AND lazy.  Listen.  By your your logic we should support EVERY
FEATURE that ANY PERSON can imagine.  Everyone should have choice, right?

Wrong.  Freedom means you are free to do whatever you want.  Change it, use
it, add whatever features you think are right.  It doesn't burden ME to do
your work for you, and it doesn't give you a right to come in with your guns
blasting because we didn't put something in that YOU wanted.  It's still OUR
project.  WE the people who help.  I'm not Linus or Alan or the long list of
headliners, but I help, too.  And I don't like your fucking attitude.

> instead of chosing between an operating system they like and an operating 
> system they hate, people end up choosing between an operating system they 
> hate and an operating system they really hate.

Because some compiler 'optimizations' that might yield a couple percent
speedup on in-kernel code (a small chunk of the code that runs on a
system, I might add) will SURELY turn a user from like to hate.

> This is one of the reasons why I've never contributed to any open source 
> project: the my-way-or-the-highway attitude of the existing developer base 
> makes attempts for newbies to get inside an invintation for unnecessary 
> pain.

How high and mighty you are.  If you don't like the way I or WE or THEY run
OUR projects, feel free to do your own.  Heck, start with our source base,
and fork it off.  Run your own damn project and see how well you do.

After this, I don't WANT you on any of my projects.  BUZZ OFF.

> Unless there's some hidden section of makefile code I don't know about, you 
> can count the number of lines that would have to be changed to meet my 
> request on the fingers of one of your hands.  If you don't make the change, 
> I will consider it conclusive proof that the whole free-as-in-freedom is 
> really just free-as-in-beer.

Please fuck off,  Joseph D. Wagner.  We should take all that code out just
so we could watch you leave.  You can't make ultimatums with people who
don't care.

Why don't you go spend your time crusading for something that might matter.
How about  you go get all the distros to compile every package with every
arch specific optimization.  You're more likely to see a benefit, and you're
probably more likely to succeed at that than you are at making us care about
your sad little tyrade.

Welcome to my killfile.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

> Why don't you go spend your time crusading for something that might
> matter. How about  you go get all the distros to compile every package
> with every arch specific optimization.  You're more likely to see a
> benefit, and you're probably more likely to succeed at that than you are
> at making us care about your sad little tyrade.

This would be step 1 in that project, but I'm not going to do the other 
thousand steps to complete the project if you aren't even willing to accept 
step 1.

Not lazy, just pragmatic.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Rik van Riel]

On Wed, 22 Oct 2003, Joseph D. Wagner wrote:

> This would be step 1 in that project, but I'm not going to do the other
> thousand steps to complete the project if you aren't even willing to
> accept step 1.

If the feature is so important to you that even you
aren't willing to do the work, can you imagine how
important it must be for us ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Dave Jones]

On Wed, Oct 22, 2003 at 07:47:45PM +0600, Joseph D. Wagner wrote:
 > > Already done for 2.6
 > Version 2.6 is still in beta.  Besides, this should have been done years ago 
 > before 2.6 existed.

They were proposed for 2.4, a while back, and rejected. In part due to
the fact that these option aren't widely tested on kernel code.

 > > Last time I looked these made absolutely no difference to performance
 > > due to the only differences being on FP code.
 > So what?

You can't use FP code in the kernel.

 >This is one of the reasons why I've never contributed to any open source
 >project: the my-way-or-the-highway attitude of the existing developer base
 >makes attempts for newbies to get inside an invintation for unnecessary pain.

You're reading into this far too much.

 > If you don't make the change, I will consider it conclusive proof
 > that the whole free-as-in-freedom is really just free-as-in-beer.

Your proposed change is in part already vetoed (for sound reasons)
for 2.4, and is already included in the development branch
(where such a far-reaching change should be tested). The other part
of your proposal is completely bogus as far as the kernel is concerned.

No amount of 'threats' are going to change this.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Joseph D. Wagner]

First off, thanks Dave for having a far more polite and meaningful response 
to potty-mouth Tim Hockin.

>> So what?

> You can't use FP code in the kernel.

What can't be done today, might be done tommorrow.

I've long complained -- in this forum and in others -- that there's a lack 
of vision, or at least a lack of documented and published vision, when it 
comes to the future of kernel development.  If you're wondering why I don't 
do it myself, it's because I don't know enough of where the project is 
headed, and I can't find out because it's not documented.  Catch-22.  
However, this is entirely a separate discussion.

I am thinking of future development.  I know this point is kind of moot 
because 2.6 already adopts the change, but that hasn't stopped about a 
dozen backports of other features to previous versions of the kernel.

> You're reading into this far too much.

Perhaps I'm reading too much into this from your personal message, and if I 
have overreacted to your personal message I apologize.  However, this isn't 
the first time I've tried to help out, and deal with, the open source 
community.  The community isn't very welcoming to newcomers which has made 
me a bit short tempered when dealing with them.

> Your proposed change is in part already vetoed (for sound reasons)
> for 2.4, and is already included in the development branch
> (where such a far-reaching change should be tested). The other part
> of your proposal is completely bogus as far as the kernel is concerned.

I respectivly disagree with those reasons.  -march is gcc flag.  If it 
creates any instability (doubtful), it's really a gcc problem.  Throwing it 
in will light a fire under their @$$ to get their act together.

>> If you don't make the change, I will consider it conclusive proof
>> that the whole free-as-in-freedom is really just free-as-in-beer.

> No amount of 'threats' are going to change this.

That's not a threat, Dave.  That's a statement of fact.  If this change 
isn't put in, my opinion will be of x.  It's a fact that my opinion will be 
of this nature.  A threat would be if I took some sort of action that would 
be damning to the linux kernel project or open source as a whole, and my 
opinion -- for what it's worth -- doesn't carry enough weight to be damning 
to either.

Joseph D. Wagner

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[William Lee Irwin III]

At some point in the past, davej wrote:
>> You can't use FP code in the kernel.

On Wed, Oct 22, 2003 at 09:35:22PM +0600, Joseph D. Wagner wrote:
> What can't be done today, might be done tommorrow.
> I've long complained -- in this forum and in others -- that there's a lack 
> of vision, or at least a lack of documented and published vision, when it 
> comes to the future of kernel development.  If you're wondering why I don't 
> do it myself, it's because I don't know enough of where the project is 
> headed, and I can't find out because it's not documented.  Catch-22.  
> However, this is entirely a separate discussion.
> I am thinking of future development.  I know this point is kind of moot 
> because 2.6 already adopts the change, but that hasn't stopped about a 
> dozen backports of other features to previous versions of the kernel.

Please read up on how kernels handle saving and restoring user floating
point contexts before spraying out anything more of this kind on the list
(preferably never doing so again regardless).


-- wli

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Wed, 2003-10-22 21:35:22 +0600, Joseph D. Wagner <theman@josephdwagner.info>
wrote in message <200310222135.22968.theman@josephdwagner.info>:

> I respectivly disagree with those reasons.  -march is gcc flag.  If it 
> creates any instability (doubtful), it's really a gcc problem.  Throwing it 
> in will light a fire under their @$$ to get their act together.

It *may* happen that some things work a bit differently. This needn't be
an exact compiler error. It may be a Linux kernel source error. However,
these things are quite subtle so it might break things and you only see
it after a month or two, when you on-HDD data is already gone...

Changes like that need good tests and can't be done in a 2.4.x kernel
becase it may harm people's data or stability. These changes need to be
done in development kernels, hopefully when they start off, not when
they settle down to become the next stable release, though...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Jesse Pollard]

On Wednesday 22 October 2003 10:35, Joseph D. Wagner wrote:
[snip]
> > Your proposed change is in part already vetoed (for sound reasons)
> > for 2.4, and is already included in the development branch
> > (where such a far-reaching change should be tested). The other part
> > of your proposal is completely bogus as far as the kernel is concerned.
>
> I respectivly disagree with those reasons.  -march is gcc flag.  If it
> creates any instability (doubtful), it's really a gcc problem.  Throwing it
> in will light a fire under their @$$ to get their act together.

Based on past history of the compiler, it will have no effect. Frequently
the Kernel compile flags have had to wait a year or two before corrections
to the compiler get entered.

Or do you mean to have the kernel be MIS-compiled for a couple of years?

The change in gcc versions is what determines the changes in the compile
flags.

Try your change out. Create/use floating point in the kernel if you want.

One suggestion - for maximum effect, replace the process scheduler with
a full fair-share sheduler, with full weight computation in the kernel.
Since this calls for a small amount of floating point on each iteration,
any problems should show up quickly. Sure, it will be slow, but it will
provide a lot of testing.

Another place to have fun (if you have a GPS reciever attached), put a
small navigation module in the kernel. (use a laptop...). This uses a
LOT of floating point math. This is normally done in user mode for that
reason.

If everything appears to work as you think, no errors due to the compiler,
then submit a patch to LKML (maybe even include the navigator as another
patch). If it doesn't, try to get the GCC project to fix the problem.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Charles Cazabon]

Joseph D. Wagner <theman@josephdwagner.info> wrote:
> So what?  Some other kernel developer -- like a module/driver developer, a 
> real-time systems developer, a simulations developer, or just some guy 
> messing around (read: student) -- might really want or even need those 
> specific optimizations.

And they can.

> Isn't this whole free-as-in-freedom software thing about giving developers 
> and end-users options they wouldn't otherwise have under closed source 
> alternatives?  In that spirit, shouldn't developers have the option of 
> optimizing for those specific processors?

They do have that option.  If they itch, they'll scratch it.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[David Zaffiro]

> If you select Pentium III, the -march flag is set to i686.
> If you select Pentium 4, the -march flag is set to i686.
> If you select Athlon 4, the -march flag is set to i686.
> If you select Athlon XP, the -march flag is set to i686.

Depends on the compiler version you use...

For gcc-3.x, I'm sure your settings should be:

If you select Athlon 4, the -march flag is set to athlon
If you select Athlon XP, the -march flag is set to athlon


> I don't want to have to hand edit the makefiles just to optimize my kernel.  

The kernel itself has evolved to its current state because people hand-edited it. The feature you request may be added in the future, it will only be added faster if you care enough to do it yourself and send a patch to this list to share it with others...

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Rob]

> I don't want to have to hand edit the makefiles just to optimize my kernel.
> I think this change is simple enough to do, and would allow kernel
> developers the option of processor-specific optimizations in the future.

yea, it's simple enough to do.
/usr/src/linux-2.4.22/Makefile, line 94. Add "-march *" as you wish.
Now all that talent was wasted on this, all this time... for something so 
small, only that you want that simple fix made available for everyone. DIY 
like the rest of the people who are already building their own kernel(!!!)

look: every time i build, i have to uncomment "export install_path=/boot".
go figure out why i never asked them to change it for me, and stop biting the 
hand that feeds.

-- 
Don't be fooled... if you can help it.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]


On 10.22, Joseph D. Wagner wrote:
> Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under 
> processor type when doing a 'make xconfig', but those selections do not 
> translate into the appropriate -mcpu and -march flags.
> 
> While the kernel on x86 architecture can be optimized in terms of generic 
> processor specifications (i.e. i386, i486, i586, i686), the kernel can't be 
> optimized beyond a i686.
> 
> If you select Pentium III, the -march flag is set to i686.
> If you select Pentium 4, the -march flag is set to i686.
> If you select Athlon 4, the -march flag is set to i686.
> If you select Athlon XP, the -march flag is set to i686.
> 
> It should be that...
> 
> If you select Pentium III, the -march flag is set to pentium3.
> If you select Pentium 4, the -march flag is set to pentium4.
> If you select Athlon 4, the -march flag is set to athlon-4.
> If you select Athlon XP, the -march flag is set to athlon-xp.
> 
> I don't want to have to hand edit the makefiles just to optimize my kernel.  
> I think this change is simple enough to do, and would allow kernel 
> developers the option of processor-specific optimizations in the future.
> 
> TIA.
> 
> Joseph D. Wagner

I have sent the attached patches sometimes to the list/Marcelo, and they
have been rejected to the moment because:
- gcc can spit some new instructions, reorganize code and other things when
  you jump from i686 to pentium3, for example.
- There can be bugs both in gcc and in the kernel that can be triggered by
  >i686 optimizations/code.
- This is not safe for a stable kernel, it was done in 2.5, bugs appeared,
  were corrected, and so on, 'cause this was a development kernel.

BTW, I use this regularly, and have not found any bugs, but I admit it is
unsafe. I also advocate for a pII split (I use a dual PII ;).
There are some other specific code that could be used in the kernel,
for example mb() and so on can be implemented with {m,s,l}fence in p3/p4
processors, instead of the old 'lock; insn' (attached also).

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre7-jam2 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk))

[-- Attachment #2: 22-x86-mb.bz2 --]
[-- Type: application/x-bzip, Size: 826 bytes --]

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Nick Piggin]

J.A. Magallon wrote:

>On 10.22, Joseph D. Wagner wrote:
>
>>Yes, I know you can select Pentium III, Pentium 4, Athlon, etc, under 
>>processor type when doing a 'make xconfig', but those selections do not 
>>translate into the appropriate -mcpu and -march flags.
>>
>>While the kernel on x86 architecture can be optimized in terms of generic 
>>processor specifications (i.e. i386, i486, i586, i686), the kernel can't be 
>>optimized beyond a i686.
>>
>>If you select Pentium III, the -march flag is set to i686.
>>If you select Pentium 4, the -march flag is set to i686.
>>If you select Athlon 4, the -march flag is set to i686.
>>If you select Athlon XP, the -march flag is set to i686.
>>
>>It should be that...
>>
>>If you select Pentium III, the -march flag is set to pentium3.
>>If you select Pentium 4, the -march flag is set to pentium4.
>>If you select Athlon 4, the -march flag is set to athlon-4.
>>If you select Athlon XP, the -march flag is set to athlon-xp.
>>
>>I don't want to have to hand edit the makefiles just to optimize my kernel.  
>>I think this change is simple enough to do, and would allow kernel 
>>developers the option of processor-specific optimizations in the future.
>>
>>TIA.
>>
>>Joseph D. Wagner
>>
>
>I have sent the attached patches sometimes to the list/Marcelo, and they
>have been rejected to the moment because:
>- gcc can spit some new instructions, reorganize code and other things when
>  you jump from i686 to pentium3, for example.
>- There can be bugs both in gcc and in the kernel that can be triggered by
>  >i686 optimizations/code.
>- This is not safe for a stable kernel, it was done in 2.5, bugs appeared,
>  were corrected, and so on, 'cause this was a development kernel.
>

Not that I think this should go in anyway, but the only way you ever
might get it in is if you measure significant performance improvements.
I don't think you will.

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[J.A. Magallon]

On 10.24, Ingo Oeser wrote:
> Hi James,
> 
> On Friday 24 October 2003 01:05, J.A. Magallon wrote:
> > There are some other specific code that could be used in the kernel,
> > for example mb() and so on can be implemented with {m,s,l}fence in p3/p4
> > processors, instead of the old 'lock; insn' (attached also).
> 
> The sfence part might be ok (modulo errata not known to me), but
> replacing "This Barrier not needed on x86" with an instruction means,
> that either these instructions are NOPs or we have a real BUG there.
> 
> Not using these mfence and lfence insn would mean less instructions,
> which is a good kernel optimization anyway ;-)
> 
> Puzzled
> 

Patch inlined. Credits should go to Zwane Mwaikambo <zwane@linux.realnet.co.sz>.
It adds the corresponding flags for PII) and P4, and in case thei are defined,
the *fence insn are used.

Included is also one other patch by Zwane, which states that smp_call_function
needs mb() instead of wmb().

I use them regularly, so they look safe. Are they really better ? At least they
do not touch any register, like the trick used till now.

22-x86-mb:

--- linux-2.4.21-pre5-jam1/arch/i386/config.in.orig	2003-03-07 03:50:19.000000000 +0100
+++ linux-2.4.21-pre5-jam1/arch/i386/config.in	2003-03-07 03:50:47.000000000 +0100
@@ -113,6 +113,7 @@
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_SFENCE y
 fi
 if [ "$CONFIG_MPENTIUM4" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 7
@@ -121,6 +122,9 @@
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
    define_bool CONFIG_X86_F00F_WORKS_OK y
+   define_bool CONFIG_X86_SFENCE y
+   define_bool CONFIG_X86_LFENCE y
+   define_bool CONFIG_X86_MFENCE y
 fi
 if [ "$CONFIG_MK6" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
--- linux-2.4.21-pre5-jam1/include/asm-i386/system.h.orig	2003-03-07 03:51:31.000000000 +0100
+++ linux-2.4.21-pre5-jam1/include/asm-i386/system.h	2003-03-07 03:51:40.000000000 +0100
@@ -290,16 +290,33 @@
  *
  * Some non intel clones support out of order store. wmb() ceases to be a
  * nop for these.
+ *
+ * Pentium III introduced the SFENCE instruction for serialising all store
+ * operations, Pentium IV further introduced LFENCE and MFENCE for load and
+ * memory barriers respecively.
  */
- 
+
+#ifdef CONFIG_X86_MFENCE
+#define mb()	__asm__ __volatile__ ("mfence": : :"memory")
+#else
 #define mb() 	__asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
+#endif
+
+#ifdef CONFIG_X86_LFENCE
+#define rmb()	__asm__ __volatile__ ("lfence": : :"memory")
+#else
 #define rmb()	mb()
+#endif
 
+#ifdef CONFIG_X86_SFENCE
+#define wmb()	__asm__ __volatile__ ("sfence": : :"memory")
+#else
 #ifdef CONFIG_X86_OOSTORE
 #define wmb() 	__asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
 #else
 #define wmb()	__asm__ __volatile__ ("": : :"memory")
 #endif
+#endif /* CONFIG_X86_SFENCE */
 
 #ifdef CONFIG_SMP
 #define smp_mb()	mb()

009-smp-call-mb:

diff -u -p -B -r1.2 smp.c
--- linux-2.4.20/arch/i386/kernel/smp.c	11 Apr 2003 13:44:11 -0000	1.2
+++ linux-2.4.20/arch/i386/kernel/smp.c	11 Apr 2003 13:44:27 -0000
@@ -553,7 +553,7 @@ int smp_call_function (void (*func) (voi
 
 	spin_lock(&call_lock);
 	call_data = &data;
-	wmb();
+	mb();
 	/* Send a message to all other CPUs and wait for them to respond */
 	send_IPI_allbutself(CALL_FUNCTION_VECTOR);
 

-- 
J.A. Magallon <jamagallon()able!es>     \                 Software is like sex:
werewolf!able!es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.23-pre8-jam1 (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-4mdk))

Re: FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

[Zwane Mwaikambo]

On Mon, 27 Oct 2003, J.A. Magallon wrote:

> Patch inlined. Credits should go to Zwane Mwaikambo <zwane@linux.realnet.co.sz>.
> It adds the corresponding flags for PII) and P4, and in case thei are defined,
> the *fence insn are used.

Andi Kleen did something nice which automagically replaces barrier 
instructions in 2.6 w/ his 'alternative' code ("include/asm-i386/system.h" 
479L)

> Included is also one other patch by Zwane, which states that smp_call_function
> needs mb() instead of wmb().

Hasn't this made it into 2.4 yet? It should at least be in -ac(-pac?) i'll 
try and send it off to Marcelo again.

Thanks,
	Zwane