[lkml]   [1997]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Loop Encryption
> 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
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
Linux Plug-and-Play Hardware Support
XFree86 Matrox Team
Ottawa-Carleton Linux User's Group (OCLUG)

 \ /
  Last update: 2005-03-22 13:39    [W:0.323 / U:1.788 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site