From: Benjamin Herrenschmidt <bh40@calva.net>
To: Adrian Cox <apc@agelectronics.co.uk>,
Gabriel Paubert <paubert@iram.es>,
<linuxppc-dev@lists.linuxppc.org>
Subject: Re: PATCH: improved processor config for G3s
Date: Mon, 4 Sep 2000 12:54:46 +0200 [thread overview]
Message-ID: <20000904105446.26517@mailhost.mipsys.com> (raw)
In-Reply-To: <39B37AD2.120E2DE7@agelectronics.co.uk>
>> A rule of thumb is the following: fully SMP capable processors broadcast
>> eieio (and tlbie for that matter), others do not at least by default. On
>> an UP 750 (SMP 750 are an aberration in any case because of TLB issues),
>> I'd bet that it is more efficient to let the processor perform store
>> gathering when it can (an eieio between both stores will prevent it) and
>> to disable both ABE in the processor and store gathering in the bridge.
>> This will result in lower processor bus utilization.
>
>Remember that the processor store gathering is only capable of turning
>two 32-bit writes to uncached, nonguarded space into one 64-bit write.
>The bridge store gathering converts an arbitrary sequence of sequential
>writes into a PCI burst.
>
>The bridge store gathering should be able to produce far more IO
>improvement, and still works if the guard bit is set on the address
>space.
>
>I should have done a set of MPC107 experiments by the start of October,
>and I'll know for sure then.
Also, are you sure, Gabriel, that eieio() not beeing broadcast to the
bridge would harm ? The bridge is not allowed to do any re-ordering.
Maybe there are issues with devices not supporting burst access to
registers, but shouldn't those devices abort the burst after the first
access ?
Drivers sensitive to timing constraints must already do a read to flush
the bridge buffer, so...
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-09-04 10:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-03 13:03 PATCH: improved processor config for G3s Michel Lanners
2000-09-03 13:43 ` Benjamin Herrenschmidt
2000-09-04 9:48 ` Gabriel Paubert
2000-09-04 10:34 ` Adrian Cox
2000-09-04 10:54 ` Benjamin Herrenschmidt [this message]
2000-09-05 9:49 ` Gabriel Paubert
2000-09-05 10:50 ` Benjamin Herrenschmidt
2000-09-05 11:06 ` Gabriel Paubert
2000-09-05 11:32 ` Adrian Cox
2000-09-04 17:51 ` Michel Lanners
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=20000904105446.26517@mailhost.mipsys.com \
--to=bh40@calva.net \
--cc=apc@agelectronics.co.uk \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paubert@iram.es \
/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.