Re: MM instruction and the pipeline

Liste des GroupesRevenir à c arch 
Sujet : Re: MM instruction and the pipeline
De : sfuld (at) *nospam* alumni.cmu.edu.invalid (Stephen Fuld)
Groupes : comp.arch
Date : 21. Oct 2024, 04:30:45
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vf4ht5$pqst$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
On 10/20/2024 5:25 PM, MitchAlsup1 wrote:
On Sun, 20 Oct 2024 15:57:59 +0000, Paul A. Clayton wrote:
 
On 10/16/24 5:14 PM, MitchAlsup1 wrote:
On Wed, 16 Oct 2024 20:48:39 +0000, Paul A. Clayton wrote:
>
>
Here is a question that I will leave to Mitch:
>
Can a MM that has confirmed permissions commit before it has been
performed such that uncorrectable errors would be recognized not
on read of the source but on later read of the destination?
>
A Memory Move does not <necessarily> read the destination. In
order to make the data transfers occur in cache line sizes,
The first and the last line may be read, but the intermediate
ones are not read (from DRAM) only to be re-written. An
implementation with byte write enables might not read any
of the destination lines.
>
I was referring to a following instruction reading the
destination.
>
Then there is the issue with uncorrectable errors at the
receiving cache. The current protocol has the sender (core)
not release his write buffer until LLC has replied that
the data arrived without ECC trouble. Thus, the instruction
causing the latent uncorrectable error is not retired until
the data has arrived successfully at LLC.
>
I was thinking primarily about uncorrectable errors in the
source. It would be convenient to software for MM to fail early on
an uncorrectable source error. It would be a little less
convenient (and possibly more complex in hardware) to generate an
ECC exception at the end of the MM instruction (or when it
pauses from a context switch).
 As I describe above, all errors are detected at source read,
precisely so that they can be detected or recovered.
 
With source-signaled errors, MM might be used to scrub memory
(assuming the microarchitecture did not optimize out copies
onto self as nops☺).
>
Not signaling the error until the destination is read some time
later prevents software from assuming the copy was correct at the
time of copying, but allows a copy to commit once all permissions
have been verified.
 The real question, here, is: if you have corrupted data in memory
and overwrite it, in its entirety, do you have to detect the error ??
should you detect the error, or should overwriting the error make
it "go away" ???
 
I could see some wanting to depend on the copy checking data
validity synchronously, but some might be okay with a quasi-
synchronous copy that allows the processor to continue doing work
outside of the MM.
>
As I mentioned before, Yes I intend to allow other instructions
to operate concurrently with MM, but I also expect MM to consume
all of L1 cache bandwidth. Just like LD L1-L2-miss operates
concurrently with FDIV.
>
For large copies, I could see having the copying done at L2 or
even L3 with distinct address generation (at least within a page,
 As you get farther out than L1; you end up not having a TLB to
translate page crossing addresses.
Yes, but once you translate the starting address of a page, which you can tell from the low order bits X bits (X depends on page size) being zero, you don't need to translate again until the next page crossing.
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)

Date Sujet#  Auteur
16 Oct 24 * MM instruction and the pipeline13Stephen Fuld
16 Oct 24 +* Re: MM instruction and the pipeline3MitchAlsup1
17 Oct 24 i`* Re: MM instruction and the pipeline2Stephen Fuld
17 Oct 24 i `- Re: MM instruction and the pipeline1MitchAlsup1
16 Oct 24 `* Re: MM instruction and the pipeline9Paul A. Clayton
16 Oct 24  `* Re: MM instruction and the pipeline8MitchAlsup1
20 Oct 24   `* Re: MM instruction and the pipeline7Paul A. Clayton
21 Oct 24    +* Re: MM instruction and the pipeline3MitchAlsup1
21 Oct 24    i+- Re: MM instruction and the pipeline1Stephen Fuld
22 Oct 24    i`- Re: MM instruction and the pipeline1MitchAlsup1
21 Oct 24    `* Re: MM instruction and the pipeline3Anton Ertl
21 Oct 24     `* Re: MM instruction and the pipeline2Michael S
22 Oct 24      `- Re: MM instruction and the pipeline1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal