Liste des Groupes | Revenir à c arch |
Scott Lurndal wrote:Done right, it is jus a apart of I/O MMU address translation
>"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:>MitchAlsup1 wrote:>
>>>>
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.
It would be more logical, I think, to simply build the functionality
into the controller (when the source and destination are devices
attached to that controller (e.g. SATA, SAS or nVME)). IIRC,
that sort of functionality was available on some SCSI controllers.
>
For the case where devices are on multiple controllers, PCI express
peer-to-peer would be the appropriate solution. There's no need
for the CPU and cache complex to be involved at all.
>
Yes, thank you. The PCI Express option was the kind of thing I was
thinking of. Since it is more general than the "in controller option",
if you implement it at the PCI level, then you don't need the
controller option.
But even though the savings are real, given the limited use case forWith an I/O MMU it pretty much drops out for free.
the feature, I question if it is worth the trouble.
>Shades of channel programs...>
>
>
Not nearly as flexible as channel programs, nor with their overhead.
>
>
Les messages affichés proviennent d'usenet.