Messages in this thread |  | | | Date | Fri, 31 Oct 2003 19:26:51 -0500 | | From | Ben Slusky <> | | Subject | Re: [PATCH] remove useless highmem bounce from loop/cryptoloop |
| |
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 - 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/
|  |