Path: ...!news.tomockey.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: MM instruction and the pipeline
Date: Sun, 20 Oct 2024 20:30:45 -0700
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <vf4ht5$pqst$1@dont-email.me>
References: <venkii$23b6b$1@dont-email.me> <vep8rb$2d8ru$1@dont-email.me>
 <bf46a508f4e6bbe44846078a50af63b7@www.novabbs.org>
 <vf39a8$fr1q$1@dont-email.me>
 <aa58a1a08f09adf4539bcafef4e853d8@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 21 Oct 2024 05:30:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="42fb1e9f9f04771c0c95b70da8fbdd65";
	logging-data="846749"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZcETPpbJM7M7RUTEtNz9f94ZdhDZ2GsY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:WsJmvhmik6BJ//8QYvlbXsE86TM=
In-Reply-To: <aa58a1a08f09adf4539bcafef4e853d8@www.novabbs.org>
Content-Language: en-US
Bytes: 4673

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)