Jens Axboe wrote:
> On Fri, Mar 15 2002, Jari Ruusu wrote:
> > If there is any chance of being merged to mainline kernel, I will fix these
> > "hurt the eyes" formatting issues.
>
> I think there is. At least I can safely say there's no chance it will be
> merged if these things aren't fixed. So take your pick :-)
OK, I have fixed above mentioned formatting issues. A patch is attached.
And, about sleeping in loop_make_request(), I have also changed the code in
such way that it defaults to code that may sleep in loop_make_request(). But
non-sleeping code is still present (but not currently used), like this:
#if 1
may-sleep-in-loop_make_request-code-here
#else
non-sleeping-loop_make_request-code-here
#endif
> > > BTW, it looks like you are killing LO_FLAGS_BH_REMAP?! Why? This is a
> > > very worthwhile optimization.
> >
> > Removing it simplified the code a lot. Doing remap direcly from
> > loop_make_request() would probably be more effective. Just remap and return
>
> LOTS more effective. Please don't kill this functionality. I don't buy
> the simplification argument.
This new patch does not remove LO_FLAGS_BH_REMAP optimization.
> > 1 from loop_make_request() like LVM code does.
>
> And like loop currently does...
2.4.19-pre3 loop code wanders to loop_get_buffer() and transfer function in
LO_FLAGS_BH_REMAP optimization case.
My version is simpler than yours:
if (lo->lo_flags & LO_FLAGS_BH_REMAP) {
rbh->b_rsector += (lo->lo_offset >> 9);
rbh->b_rdev = lo->lo_device;
return 1;
}
Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>
-
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/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:19 EST