public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH linux-2.6-block:master] blk: reimplement elevator switch
Date: Thu, 20 Oct 2005 14:25:05 +0200	[thread overview]
Message-ID: <20051020122505.GG2811@suse.de> (raw)
In-Reply-To: <20051019123648.GA31257@htj.dyndns.org>

On Wed, Oct 19 2005, Tejun Heo wrote:
>  Hello, Jens.
> 
>  This patch reimplements elevator switch.  This patch assumes generic
> dispatch queue patchset is applied.
> 
>  * Each request is tagged with REQ_ELVPRIV flag if it has its elevator
>    private data set.
>  * Requests which doesn't have REQ_ELVPRIV flag set never enter
>    iosched.  They are always directly back inserted to dispatch queue.
>    Of course, elevator_put_req_fn is called only for requests which
>    have its REQ_ELVPRIV set.
>  * Request queue maintains the current number of requests which have
>    its elevator data set (elevator_set_req_fn called) in
>    q->rq->elvpriv.
>  * If a request queue has QUEUE_FLAG_BYPASS set, elevator private data
>    is not allocated for new requests.
> 
>  To switch to another iosched, we set QUEUE_FLAG_BYPASS and wait until
> elvpriv goes to zero; then, we attach the new iosched and clears
> QUEUE_FLAG_BYPASS.  New implementation is much simpler and main code
> paths are less cluttered, IMHO.

Wonderful! Applied as-is, I didn't make any changes to this one. I agree
it's much cleaner than the previous approach, both in the code and in
killing the request_queue and request_list members.

I'm going to make a little few tweaks:

- The naming, QUEUE_FLAG_BYPASS isn't really clear. I don't know what
  this means without looking at specific parts of the code. Testing of
  same flag in various locations would also be preferred instead of
  passing priv around and cluttering the function parameters, however we
  should split the queue flags a little for this. Basically into an
  atomic and non-atomic part. So I'll leave that alone for now.

- The msleep(100) seems a little too slow. With the switching being more
  efficient now, in 100msecs we can complete lots of requests.

-- 
Jens Axboe


  reply	other threads:[~2005-10-20 12:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-19 12:36 [PATCH linux-2.6-block:master] blk: reimplement elevator switch Tejun Heo
2005-10-20 12:25 ` Jens Axboe [this message]
2005-10-20 13:54   ` Tejun Heo
2005-10-20 14:07     ` Jens Axboe

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=20051020122505.GG2811@suse.de \
    --to=axboe@suse.de \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox