Jari Ruusu <jari.ruusu@pp.inet.fi> wrote:
>
> Andries.Brouwer@cwi.nl wrote:
> > akpm:
> > > You'll note that loop.c goes from (page/offset/len) to (addr/len),
> > > and this transfer function then immediately goes from (addr,len)
> > > to (page/offset/len). That's rather silly ..
> >
> > Changing that would kill all existing modules that use the loop device.
> >
> > Maybe nobody cares. Then we can do so in a subsequent patch.
>
> I care. Please don't break the transfer function prototype.
Why?
> I don't know if you guys have realized it or not, but cryptoloop+cryptoapi
> is the slowest possible loop crypto implementation on the planet. Before you
> guys sacrifice loop performance with cryptoloop only stuff, you may want to
> do google search for "loop-AES" (twice as fast on most modern boxes) and
> choose to preserve fast interfaces that other implementations depend on.
It's not clear what point you're actually trying to make here. But it's
worth pointing out that the current transfer function interface can be sped
up (a bit) by going to a pageframe-based one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:19 EST