From: "David S. Miller" <davem@redhat.com>
To: lm@bitmover.com
Cc: torvalds@transmeta.com, frankeh@us.ibm.com,
mkravetz@beaverton.ibm.com, linux-kernel@vger.kernel.org,
wscott@bitmover.com
Subject: Re: [RFC][PATCH] Scalable Scheduling
Date: Wed, 8 Aug 2001 11:53:28 -0700 [thread overview]
Message-ID: <200108081853.LAA02747@pizda.ninka.net> (raw)
In-Reply-To: <20010808111844.S23718@work.bitmover.com> (message from Larry McVoy on Wed, 8 Aug 2001 11:18:44 -0700)
In-Reply-To: <Pine.LNX.4.33.0108081041260.8047-100000@penguin.transmeta.com> <Pine.LNX.4.33.0108081058420.8103-100000@penguin.transmeta.com> <20010808111844.S23718@work.bitmover.com>
Date: Wed, 8 Aug 2001 11:18:44 -0700
From: Larry McVoy <lm@bitmover.com>
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
davem@redhat.com
next prev parent reply other threads:[~2001-08-08 18:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-08 17:32 Hubertus Franke
2001-08-08 17:43 ` Linus Torvalds
2001-08-08 18:00 ` Linus Torvalds
2001-08-08 18:18 ` Larry McVoy
2001-08-08 18:28 ` Mike Kravetz
2001-08-08 19:06 ` Daniel Phillips
2001-08-08 19:14 ` Linus Torvalds
2001-08-08 19:27 ` Victor Yodaiken
2001-08-08 18:53 ` David S. Miller [this message]
2001-08-10 23:58 ` Chris Wedgwood
-- strict thread matches above, loose matches on Subject: below --
2001-08-14 14:22 Erik Corry
2001-08-11 0:04 Hubertus Franke
2001-08-08 20:02 Hubertus Franke
2001-08-08 19:40 Hubertus Franke
2001-08-08 19:51 ` Victor Yodaiken
2001-08-08 19:16 Hubertus Franke
2001-08-08 19:05 Hubertus Franke
2001-08-08 16:16 Mike Kravetz
2001-08-08 16:40 ` Linus Torvalds
2001-08-08 17:05 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200108081853.LAA02747@pizda.ninka.net \
--to=davem@redhat.com \
--cc=frankeh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=mkravetz@beaverton.ibm.com \
--cc=torvalds@transmeta.com \
--cc=wscott@bitmover.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®