All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jari Ruusu <jari.ruusu@pp.inet.fi>
Cc: Andrea Arcangeli <andrea@suse.de>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	Herbert Valerio Riedel <hvr@hvrlab.org>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.4.19pre3aa2
Date: Wed, 20 Mar 2002 08:54:31 +0100	[thread overview]
Message-ID: <20020320075431.GG25171@suse.de> (raw)
In-Reply-To: <20020314032801.C1273@dualathlon.random> <3C912ACF.AF3EE6F0@pp.inet.fi> <20020315105621.GA22169@suse.de> <3C9230C6.4119CB4C@pp.inet.fi> <20020318191352.GF28487@suse.de> <3C97C924.A9A256F6@pp.inet.fi>

On Wed, Mar 20 2002, Jari Ruusu wrote:
> 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.

Super!

> 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

The solution I prefer is to have loop_make_request() block when we run
out of pre-allocated buffers, ie similar to "normal" block drivers when
they run out of request slots. This provides a nice throttling mechanism
and makes sure that loop doesn't eat into the memory polls too heavily.

In any way, do it one way and remove the other.

> > > > 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.

Good.

> > > 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;
>         }               

So the 'new' version does exactly the same, but doesn't do it in
loop_get_buffer().

-- 
Jens Axboe


  reply	other threads:[~2002-03-20  7:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-14  2:28 2.4.19pre3aa2 Andrea Arcangeli
2002-03-14 12:32 ` 2.4.19pre3aa2 Dave Jones
2002-03-14 12:37   ` 2.4.19pre3aa2 Andrea Arcangeli
2002-03-14 12:46   ` 2.4.19pre3aa2 Jeff Garzik
2002-03-14 12:59     ` 2.4.19pre3aa2 Dave Jones
2002-03-14 15:53   ` 2.4.19pre3aa2 Bill Davidsen
2002-03-14 16:12     ` 2.4.19pre3aa2 Andrea Arcangeli
2002-03-14 16:16       ` 2.4.19pre3aa2 Dave Jones
2002-03-14 16:32         ` 2.4.19pre3aa2 Andrea Arcangeli
2002-03-16  1:26       ` 2.4.19pre3aa2 Mike Fedyk
2002-03-14 16:13     ` 2.4.19pre3aa2 Dave Jones
2002-03-14 17:16       ` 2.4.19pre3aa2 Bill Davidsen
2002-03-14 21:16   ` 2.4.19pre3aa2 H. Peter Anvin
2002-03-14 18:00 ` 2.4.19pre3aa2 Andrew Morton
2002-03-14 22:57 ` 2.4.19pre3aa2 Jari Ruusu
2002-03-15 10:56   ` 2.4.19pre3aa2 Jens Axboe
2002-03-15 11:06     ` 2.4.19pre3aa2 Jens Axboe
2002-03-15 17:35     ` 2.4.19pre3aa2 Jari Ruusu
2002-03-15 17:57       ` 2.4.19pre3aa2 Andrea Arcangeli
2002-03-16 12:10         ` 2.4.19pre3aa2 Jari Ruusu
2002-03-16 13:54           ` 2.4.19pre3aa2 Andrea Arcangeli
2002-03-18 19:13       ` 2.4.19pre3aa2 Jens Axboe
2002-03-19 23:26         ` 2.4.19pre3aa2 Jari Ruusu
2002-03-20  7:54           ` Jens Axboe [this message]
2002-03-20 18:16             ` 2.4.19pre3aa2 Jari Ruusu
2002-03-20 14:21           ` 2.4.19pre3aa2 Herbert Valerio Riedel
2002-03-15 12:19   ` 2.4.19pre3aa2 Herbert Valerio Riedel
2002-03-15 17:36     ` 2.4.19pre3aa2 Jari Ruusu
2002-03-15 18:36       ` 2.4.19pre3aa2 Herbert Valerio Riedel
2002-03-16 12:12         ` 2.4.19pre3aa2 Jari Ruusu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020320075431.GG25171@suse.de \
    --to=axboe@suse.de \
    --cc=andrea@suse.de \
    --cc=hvr@hvrlab.org \
    --cc=jari.ruusu@pp.inet.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.