Re: [PATCH] remove useless highmem bounce from loop/cryptoloop

[Ben Slusky <sluskyb@paranoiacs.org>]

On Fri, 31 Oct 2003 01:55:00 -0800, Andrew Morton wrote:
> Ben Slusky <sluskyb@paranoiacs.org> wrote:
> > The current memory allocation procedure really is inadequate. It worked
> > ok up thru 2.4 because the loop device was used almost exclusively
> > as a nifty hack to make an initrd or to double-check the ISO you just
> > created.
> 
> mm..  Last time I looked the 2.4 loop driver is fairly robust from the
> memory management point of view.

Memory management is fine after we've allocated the memory. The problem is
in the approach of going back to square one if only n-1 out of n pages
could be allocated. That approach is inherently prone to deadlock.

> Here's the patch; feel free to benchmark it.  It kills 200 lines of code
> and unifies the block-backed and file-backed codepaths.  That surely is a
> good thing.

I will benchmark it soon... meantime I have a real concern about what
you've done to block-backed loop reads. Now the loop thread has to read
and transform (decrypt) each bio, whereas in the old code reading was
done asynchronously in the backing block device driver, leaving the loop
thread free to do some transforms at the same time. I don't see how this
could not hurt performance.

> It fixes bug 1198 too, it appears.

The file-backed loop code path allocates memory in a sane fashion.
File-backed loops never manifested the bug.

-- 
Ben Slusky                      | A free society is a society
sluskyb@paranoiacs.org          | where it is safe to be
sluskyb@stwing.org              | unpopular.
PGP keyID ADA44B3B              |               -Adlai Stevenson