From: Dominic Sweetman <dom@mips.com>
To: "Mitchell, Earl" <earlm@mips.com>
Cc: "Wolfgang Denk" <wd@denx.de>,
"Kevin D. Kissell" <kevink@mips.com>,
"Sathesh Babu Edara" <satheshbabu.edara@analog.com>,
<linux-mips@linux-mips.org>
Subject: RE: [processor frequency]
Date: Tue, 10 Jan 2006 09:36:49 +0000 [thread overview]
Message-ID: <17347.32817.144103.968382@mips.com> (raw)
In-Reply-To: <3CB54817FDF733459B230DD27C690CEC010495E3@Exchange.MIPS.COM>
My colleague Earl writes:
> The desktop/server guys typically use much larger caches (i.e. >= 512K)
> and most have L2, compared to embedded systems which typically use less
> without an L2. So I'd also expect embedded guys using small caches to see
> larger decreases in performance due to more cache misses (i.e. more
> interrupts produce more evictions).
It's certainly true that running an interrupt routine (even one which
doesn't lead to any scheduling activity) will cause some cache
traffic. But it is important to keep the relative timescales in mind.
With an averagely bad memory system, evicting and replacing a cache
line costs 150ns read latency, with a 100ns writeback (notionally done
"in the background" just after the read) on about one miss in four...
Let's make some pessimistic assumptions. Suppose an interrupt routine
displaces 2KB of code and data and uses 32-byte cache lines, and we
assume the process happens twice as the background process refills the
cache to its liking. Then we'll get 120 odd reads, which will cost
about 20us, about 2% of total time on a 1KHz clock. That doesn't
sound like it should be a huge effect.
It would be better to measure it, though.
--
Dominic Sweetman
MIPS Technologies.
WARNING: multiple messages have this Message-ID (diff)
From: Dominic Sweetman <dom@mips.com>
To: "Mitchell, Earl" <earlm@mips.com>
Cc: Wolfgang Denk <wd@denx.de>, "Kevin D. Kissell" <kevink@mips.com>,
Sathesh Babu Edara <satheshbabu.edara@analog.com>,
linux-mips@linux-mips.org
Subject: RE: [processor frequency]
Date: Tue, 10 Jan 2006 09:36:49 +0000 [thread overview]
Message-ID: <17347.32817.144103.968382@mips.com> (raw)
Message-ID: <20060110093649.HN7mvC9R7o8cT4lwTx1zGRNblq6RS2t60tDgfr8aLGk@z> (raw)
In-Reply-To: <3CB54817FDF733459B230DD27C690CEC010495E3@Exchange.MIPS.COM>
My colleague Earl writes:
> The desktop/server guys typically use much larger caches (i.e. >= 512K)
> and most have L2, compared to embedded systems which typically use less
> without an L2. So I'd also expect embedded guys using small caches to see
> larger decreases in performance due to more cache misses (i.e. more
> interrupts produce more evictions).
It's certainly true that running an interrupt routine (even one which
doesn't lead to any scheduling activity) will cause some cache
traffic. But it is important to keep the relative timescales in mind.
With an averagely bad memory system, evicting and replacing a cache
line costs 150ns read latency, with a 100ns writeback (notionally done
"in the background" just after the read) on about one miss in four...
Let's make some pessimistic assumptions. Suppose an interrupt routine
displaces 2KB of code and data and uses 32-byte cache lines, and we
assume the process happens twice as the background process refills the
cache to its liking. Then we'll get 120 odd reads, which will cost
about 20us, about 2% of total time on a 1KHz clock. That doesn't
sound like it should be a huge effect.
It would be better to measure it, though.
--
Dominic Sweetman
MIPS Technologies.
next prev parent reply other threads:[~2006-01-10 9:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 22:00 [processor frequency] Mitchell, Earl
2006-01-09 22:00 ` Mitchell, Earl
2006-01-09 23:05 ` Wolfgang Denk
2006-01-10 9:36 ` Dominic Sweetman [this message]
2006-01-10 9:36 ` Dominic Sweetman
-- strict thread matches above, loose matches on Subject: below --
2006-01-09 9:00 Kevin D. Kissell
2006-01-09 21:23 ` [processor frequency] Wolfgang Denk
2006-01-09 21:53 ` Kevin D. Kissell
2006-01-09 23:01 ` Wolfgang Denk
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=17347.32817.144103.968382@mips.com \
--to=dom@mips.com \
--cc=earlm@mips.com \
--cc=kevink@mips.com \
--cc=linux-mips@linux-mips.org \
--cc=satheshbabu.edara@analog.com \
--cc=wd@denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.