Re: Arguments for a sane ISA 6-years later

MitchAlsup1 wrote:

On Fri, 2 Aug 2024 14:05:25 +0000, Scott Lurndal wrote:
 

mitchalsup@aol.com (MitchAlsup1) writes:

On Thu, 1 Aug 2024 20:34:28 +0000, Scott Lurndal wrote:
 
 

In addition, ARM64 CPUs include allocation hints in
the memory type such as 'read allocate', 'transient read
allocate', 'write allocate' as well has having optionally
multiple coherency domains (inner and outer sharable).

 
Sorry, I don't understand the word 'allocate' ?!?

 
"allocate a cache line".
 
Example would be a DMA request with the 'read allocate' hint
is allowed to be allocated in LLC instead of being stored in
DRAM.
 
Used when software expects the DMA data to be immediately.

 
Thanks for the explanation.
 
In my case LLC is simply the front end for DRAM so a device
write will spew data into LLC where it will wait to be written.

 
I'm not sure that's a good idea.    Large DMAs are common
(e.g. reading pages of data in a single I/O) and the data
from the DMA is not always used by the CPU.  Evicting LLC lines to
accomodate a file copy, for example, seems less than optimal.

 
Fair enough. But after thinking abut this for a while, does the
process performing the file copy even know it is doing a file
copy ?? for example::
 
cat ../mydir/myfile > ../yourdir/yourfile
 
Which kind of applications know they are doing Input that will
not be used rather presently ??
 
It seems to me that a file copy application would understand
that writing of DRAM is irrelevant when the true destination
is another sector on another disk, and any means to connect
those does is more than sufficient.

I suppose you could creaate a mecnahism that fed the data from the
"read" DMA directly to the "Write DMA, thus bypassing not only the
cache, but the saving DRAM bandwidth as well.  This would help on
copies, and perhaps things like defrag and backup.  But I suspect that
the savings are not worth the effort.




--
 - Stephen Fuld
(e-mail address disguised to prevent spam)