lkml.org 
[lkml]   [2002]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.19pre3aa2
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>[unhandled content-type:application/x-gzip]
\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.078 / U:0.548 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site