Re: [RFC][PATCH] Scalable Scheduling

[Hubertus Franke]

There is a project that some of our people here are involved with called
SIGMA.
They are looking at standardizing interfaces for this across all platforms.
I'll dig out an http and forward to the list.

Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [e-mail]
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003

"David S. Miller" <[e-mail]> on 08/08/2001 02:53:28 PM

To:   [e-mail]
cc:   [e-mail], Hubertus Franke/Watson/IBM@IBMUS,
      [e-mail], [e-mail],
      [e-mail]
Subject:  Re: [RFC][PATCH] Scalable Scheduling

   Date:  Wed, 8 Aug 2001 11:18:44 -0700
   From: Larry McVoy <[e-mail]>

   Someobdy really ought to take the time to make a cache miss counter
program
   that works like /bin/time.  So I could do

        $ cachemiss lat_ctx 2
        10123 instruction, 22345 data, 50432 TLB flushes

   Has anyone done that?  If so, then what would be cool is if each of
these
   wonderful new features that people propose come with cachemiss results
for
   the related part of LMbench or some other benchmark.

On some platforms, such an app can basically be written already.

The kernel support is there for sparc64 wrt. the cache
miss stuff.  It uses the cpu performance counter stuff.
Have a look at linux/include/asm-sparc64/perfctr.h to see
what I mean.

The performance counters are fancy enough that you can
ask them to do stuff like:

1) tell me D-cache misses in user and/or kernel mode
2) tell me D-cache misses that hit the E-cache
   in user and/or kernel mode
3) tell me I-cache misses, but only those which actually
   ended up stalling the pipeline
4) tell me E-cache misses, where the chip was not able
   to get granted to memory bus immediately
5) Same as #4, but how many total bus cycles were spent
   waiting for bus grant for the E-cache miss

Later,
David S. Miller
[e-mail]