Re: [BENCHMARK] Corrected gcc3.2 v gcc2.95.3 contest results

From: Richard B. Johnson (
Date: Mon Sep 23 2002 - 08:15:41 EST

On Mon, 23 Sep 2002, Erik Andersen wrote:

> On Mon Sep 23, 2002 at 08:30:21PM +1000, Con Kolivas wrote:
> > Yes you make a very valid point and something I've been stewing over privately
> > for some time. contest runs benchmarks in a fixed order with a "priming" compile
> > to try and get pagecaches etc back to some sort of baseline (I've been trying
> > hard to make the results accurate and repeatable).
> It would sure be nice for this sortof test if there were
> some sort of a "flush-all-caches" syscall...
> -Erik

I think all you need to do is reload the code-segment register
and you end up flushing caches in ix86.

# This forces a cache-line refill by reloading the code-segment
# segment register. This would normally slow things down. However,
# if I put this at the start of a procedure that suffers a cache-line
# refill within the procedure, it is possible to speed things up.
.section .text
.global cflush
.type cflush,@function

cflush: pushl %cs # Put code segment on the stack
        pushl $goto # Put offset on the stack
        lret # Do a 'long' return (reloads cs)
goto: ret

Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:38 EST