Sorry for the previous base64 message
#define BAD_ENGLISH
Hi,
I have a loop device with a new do_lo_request , the old loop was a
bit slow in concurrent acces.
When I put cdrom trought the old loop.c and start to play mp3 from it
(for example) , if I copy a file from the cd wich is far of the first
the result is this :
play mp3
copy the file ...
(the music stops)
(intensive read for 3 or 4 seconds)
(the music start again)
.
.
.
.
end of the copy
With the new do_lo_request there are only short stops <1 second (like
if I read it without the loop device) so I think I have do the
concurrent acces faster.
The trick is to merge the request first and request all at a time to the
real devices so they can do their own read strategies.
But to do that I have modified the ll_rw_block.c with a new semaphore to
do it faster without block the system, I will talk about it later.
There is only one disadventage, this new implementatio don't support
offsets that are not a multiple of 512, it could be solved.(I hope)
But I'm new on this and I don't know how the kernel development works ,
Who has to test the changes?
and How I send the changes?
thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:18 EST