[cap-talk] DMA vs programmed I/O (was: Midori in The Register)

[Kenneth Hamer-Hodges]

In the absence of any real data to press this discussion far I can certainly
claim that 
1. The number of cores would be more numerous per unit area if the
real-estate was focused on only one style of typed hardware - perhaps
double.
2. The additional code and real-time required to set up 'typed' I/O tasks
and deal with DMA interrupts adds accidental performance overheads.
3. The use of DMA contorts the natural - intrinsic - flow of control and
added various scheduling delay points that also have an impact.
4. The style lead back to privileged modes and that is a very slippery slope
that eventually leads back to the problems we presently face. 

One only has to see the mess we have on our hands with virtualization
hardware and Rutkowska's finding on Blue Pill to become a believer - see
http://theinvisiblethings.blogspot.com/ 
In conclusion I see the performance argument as misguided when considered
with respect to internet I/O and TCB security issues. (btw I am not against
a high performance DMA instruction as was developed for System 250).
k

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> bounces at mail.eros-os.org] On Behalf Of David-Sarah Hopwood
> Sent: Wednesday, August 06, 2008 5:34 PM
> To: General discussions concerning capability systems.
> Subject: [cap-talk] DMA vs programmed I/O (was: Midori in The Register)
> 
> Kenneth Hamer-Hodges wrote:
> > Adding a second DMA version of typed hardware leads to a second set of
> > mechanism at risk and question about delegation to the DMA level open up
> > another Pandora's Box.
> > With multi core solution so easily available today this simplicity and
> > uniformity remain the best option for building a Trusted Computer Base.
> 
> Given that existing systems use DMA, and obtain a significant performance
> advantage from doing so *for any given number of cores*, and that new
> systems must be able to compete on performance, it seems unlikely that a
> new system design that was unable to use DMA could be successful.
> 
> I don't often make arguments in favour of performance at the expense of
> simplicity, but here the performance advantage (perceived and actual) is
> just too great. For a system using programmed I/O to be able to compete,
> the hardware would need to have enough general-purpose cores that you
> don't have anything worthwhile to do with some of them apart from I/O.
> Even that assumes that the required I/O bandwidth won't increase as the
> number of cores does, which is probably not a valid assumption,
> especially for the applications that are most in need of high performance.
> 
> If anything, the importance of having specialized I/O "cores" (whether
> or not they look like conventional DMA controllers) increases with
> multicore, because this specialization is a more efficient use of the
> available chip area and power budget: a general-purpose core is area-
> and power-inefficient for doing I/O, and an I/O core can't be made
> to do general computation without increasing its area and power usage.
> Actually it makes some sense to further specialize the I/O cores to
> handle specific physical-layer protocols, as the Tile64
> <http://www.tilera.com/products/processors.php> does, for example.
> (I have no connection with Tilera.)
> 
> --
> David-Sarah Hopwood
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk