public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Peter T. Breuer" <ptb@it.uc3m.es>
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: plugging in 2.4. Does it work?
Date: Tue, 20 Feb 2001 23:54:00 +0100	[thread overview]
Message-ID: <20010220235400.A811@suse.de> (raw)
In-Reply-To: <200102202241.f1KMftG31691@oboe.it.uc3m.es>
In-Reply-To: <200102202241.f1KMftG31691@oboe.it.uc3m.es>; from ptb@it.uc3m.es on Tue, Feb 20, 2001 at 11:41:55PM +0100

On Tue, Feb 20 2001, Peter T. Breuer wrote:
> More like "how does one get it to work".
> 
> Does anyone have a simple recipe for doing plugging right in 2.4?
> I'm doing something wrong.
> 
> When I disable plugging on my block driver (by registering a no-op
> plugging function), the driver works fine.  In particular my end_request
> code works fine - it does an if end_that_request_first return;
> end_that_request_last on the request to murder. Here it is
> 
>  int my_end_request(struct request *req) {
>    unsigned long flags; int dequeue = 0;
>    spin_lock_irqsave(&io_request_lock, flags);
>    if (!req->errors) {
>      while (req->nr_sectors > 0) {
>        printk( KERN_DEBUG "running end_first on req with %d sectors\n",
>               req->nr_sectors);
>        if (!end_that_request_first (req, !req->errors, DEVICE_NAME))
>          break;
>      }
>    }
>    printk( KERN_DEBUG "running end_first on req with %d sectors\n",
>             req->nr_sectors);
>    if (!end_that_request_first (req, !req->errors, DEVICE_NAME)) {
>      printk( KERN_DEBUG "running end_last on req with %d sectors\n",
>               req->nr_sectors);
>      end_that_request_last(req);
>      dequeue = 1;
>    }
>    spin_unlock_irqrestore(&io_request_lock, flags);
>    return dequeue;
>  }

Could this snippet possibly become more unreadable :-)
Firstly, I hope that the dequeue var does not return whether the 
request should be dequeued or not. Because if you do it after
end_that_request_last, you are totally screwing the request
lists. Maybe this is what's going wrong?

> I've discovered that
> 
> 1) setting read-ahead to 0 disables request agregation by some means of
> which I am not aware, and everything goes hunky dory.

Most likely what you are seeing happen is that we will do a
wait_on_buffer before we have a chance to merge this request on
the queue. Do writes, and you'll see lots of merging.

> 2) setting read-ahead to 4 or 8 seems to be safe. I see 4K requests
> being formed and treated OK.
> 
> 3) disabling plugging stops request aggretaion and makes everything
> safe.
> 
> Any clues? Is the trick just "powers of 2"? how is one supposed to
> handle plugging? Where is the canonical example. I can't see any driver
> that does it.

There's no trick, and no required values. And there's really no special
trick to handling clustered requests. Either you are doing scatter
gather and setup your sg tables by going through the complete buffer
list on the request, or you are just transferring to rq->buffer the
amount specified by current_nr_sectors. That's it. Really.

-- 
Jens Axboe


  reply	other threads:[~2001-02-20 22:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-20 22:41 plugging in 2.4. Does it work? Peter T. Breuer
2001-02-20 22:54 ` Jens Axboe [this message]
2001-02-20 23:27   ` Peter T. Breuer
2001-02-20 23:37     ` Jens Axboe
2001-02-20 23:48       ` Peter T. Breuer
2001-02-20 23:52         ` Jens Axboe
2001-02-20 22:58 ` Jens Axboe
2001-02-20 23:32   ` Peter T. Breuer
  -- strict thread matches above, loose matches on Subject: below --
2001-02-21 15:36 Peter T. Breuer
2001-02-21 17:27 ` Jens Axboe
2001-02-21 17:54   ` Peter T. Breuer

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=20010220235400.A811@suse.de \
    --to=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptb@it.uc3m.es \
    /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