FEATURE REQUEST: Specific Processor Optimizations on x86 Architecture

DISCUSSION Ihar 'Philips' Filipau 3 participants 4 messages Oct 23, 2003 – Oct 27, 2003 6 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ihar 'Philips' Filipau

author

2003-10-23 08:33 UTC #3 lore raw

Quoted 5 lines · Michael Rozhavsky

Quoted 2 lines
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.

Signature · 5 lines

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

Ihar 'Philips' Filipau

author

2003-10-23 08:37 UTC #4 lore raw

In reply to a message not in the archive

Quoted 5 lines · Michael Rozhavsky

Quoted 2 lines
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.

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

Signature · 5 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andi Kleen

2003-10-27 18:33 UTC #8 lore raw

Quoted 9 lines · J.A. Magallon

Patch inlined. Credits should go to Zwane Mwaikambo <[email protected]>. 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

Zwane Mwaikambo

2003-10-27 21:06 UTC #9 lore raw

Quoted 4 lines · Andi Kleen

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.