Messages in this thread | | | From | "Andrew E. Mileski" <> | Subject | Re: Loop Encryption | Date | Wed, 4 Jun 1997 02:20:23 -0400 (EDT) |
| |
> P.S. Is it me, or is get_request() in drivers/block/ll_rw_blk.c > particularly complex for the simple job it does (with interrupts > disabled I might add)?
I just rewrote it. It now allocates WRITEs from one end, and READs from the other. It is faster - on average, fewer requests are searched. Is is also more fair - READs and WRITEs get clustered at the ends of the all_requests array, so a READ (higher priority) is less likely to fill up a WRITE (lower priority) slot, except when the system is busy with lots of requests.
I also rewrote get_request_wait() and eliminated __get_request_wait(). The new code has generic support for handling drivers (like loop) that require multiple requests to complete a single request. They are put to sleep BEFORE THEY CAN START until there are enough free requests - the old code could only do this for single requests.
I've been punishing the code for over 4 hours continuously now, by moving an 8 MB file to/from a deeply looped (XOR) file (mounted=loop7->loop6->loop5->loop4->loop3->loop2->loop1->loop0->file) and syncing. Works wonderfully.
The source is not yet ready for prime time (I know I can make it better), but it is available directly from me as part of my modular loop driver patch (which now supports kerneld too!).
After this, I attack the buffer cache (particularly bdflush) to improve its loop driver support.
-- Andrew E. Mileski mailto:aem@netcom.ca Linux Plug-and-Play Hardware Support http://www.redhat.com/linux-info/pnp/ XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html Ottawa-Carleton Linux User's Group (OCLUG) http://www.storm.ca/~linux/
| |