All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@domain.hid>
To: Der Herr Hofrat <der.herr@domain.hid>
Cc: Fillod Stephane <stephane.fillod@domain.hid>,
	rtai@domain.hid, adeos-main@gna.org
Subject: [Adeos-main] Re: Interrupt Latency Question
Date: Tue, 03 May 2005 18:11:19 +0200	[thread overview]
Message-ID: <4277A2A7.8050006@domain.hid> (raw)
In-Reply-To: <200505030712.j437CaU18874@domain.hid>

On 05/03/2005 09:12 AM Der Herr Hofrat wrote:
>> Hello,
>> 
>> I just run flushy on a low-end PowerPC system:
>> 
>>   XPC855xxZPnnD4 at 80 MHz: 4 kB I-Cache 4 kB D-Cache FEC present
>> 
>> Unfortunately the results are not that clear than expected. I see the
>> latency going up a bit but other activities do increase it as well
>> (telnet, ping -f). Furthermore, from run to run the latency results are
> 
> did some measurements on a number of boxes and ping -f is a bad test as
> especially on low end systems it results in the kernel more or less running
> the same code in an infinite loop - resulting in "good" values. If you want
> to see the network layer influence use NetPIPE and see the jitter jump ;)
> 
>> different. Well, I think it's a complex and arch-dependent interplay of
>> various parameters, e.g. on the system above, the caches are quite small
>> and therefore the influence of cache refills is low. When I have more
>> time I might repeat the tests on other PowerPC archs as well.
>> 
>> 
>> Apart from that, you can do little to reduce the latency degradation due
>> to cache refills and TLB misses (at least not in a portable way). Linux
>> simply requires it.
>>
> has anybody ever used gcov feedbacks for ppc ? (run load with kernel compiled
> with -fprofile-arcs recompile -fbranch-probabilities rerun load and test 
> jitter) . The PPC branch prediction should be almost ideal for this and that
> would be a fairly portable way of doing it.

I never tried that but I doubt that it will reduce cache refills and TLB
misses. I will have a closer look when time permits.

Wolfgang.



      reply	other threads:[~2005-05-03 16:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-14 14:55 [Adeos-main] RE: Interrupt Latency Question Fillod Stephane
2005-04-14 15:47 ` Philippe Gerum
2005-04-14 20:20   ` Michael Neuhauser
2005-04-14 17:15 ` [Adeos-main] " Paolo Mantegazza
2005-04-19 18:35   ` Max Krasnyansky
2005-04-20  8:06     ` Paolo Mantegazza
2005-04-20 18:10       ` Max Krasnyansky
2005-04-17  9:32 ` Wolfgang Grandegger
2005-05-03  7:12   ` Der Herr Hofrat
2005-05-03 16:11     ` Wolfgang Grandegger [this message]

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=4277A2A7.8050006@domain.hid \
    --to=wg@domain.hid \
    --cc=adeos-main@gna.org \
    --cc=der.herr@domain.hid \
    --cc=rtai@domain.hid \
    --cc=stephane.fillod@domain.hid \
    /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.