On Thu, Apr 30, 2009 at 04:52:59PM -0700, Matthew Dempsky wrote: > On Thu, Apr 30, 2009 at 4:03 PM, Ariane van der Steldt <ari...@stack.nl> > wrote: > >> ? - add new drivers that attach on specific CPUs and hook into the > >> crypto framework to provide optimized implementations > > > > Even if it isn't faster, it may allow the cpu to do something else in > > the meantime. That is a good thing. > > My wording was perhaps confusing. By "specific CPUs", I meant > specific CPU architectures. E.g., the current fastest AES > implementation for the Athlon 64 is different than the fastest AES > implementation for the Core 2.
I think if you are going to differentiate on that level, you'll not get it in the kernel. Differentiating on that level would mean we have an enormous job to keep all different implementations working. Keep in mind that OpenBSD is not an intel-central world: we also have sparc64, sparc, alpha, powerpc etc. The difference in speed is likely to only matter a number of nanoseconds and I think you'll really notice that that speed-up is dwarfed by other possible optimizations, ones that also affect other platforms positively. Optimizing this is realy difficult, since there are many factors involved: - interrupt latency if you use specific devices - scheduler latency (the openbsd scheduler is a 4.4-bsd scheduler and grants 100 msec per timeslice) Those are probably the worst offenders. If you go the route of optimizing for, for example, the Core 2, then you may notice that the I7/Nehalem has totally different characteristics, completely throwing off your optimizations. I simply don't think that granularity of optimization is worth the effort, compared to the gains. -- Ariane
