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: block devices don't work without plugging in 2.4.3
Date: Thu, 19 Apr 2001 12:51:40 +0200	[thread overview]
Message-ID: <20010419125140.M16822@suse.de> (raw)
In-Reply-To: <200104191039.f3JAdvq15198@oboe.it.uc3m.es>
In-Reply-To: <200104191039.f3JAdvq15198@oboe.it.uc3m.es>; from ptb@it.uc3m.es on Thu, Apr 19, 2001 at 12:39:57PM +0200

On Thu, Apr 19 2001, Peter T. Breuer wrote:
> Sorry to repeat .. I didn't see this go out on the list and I haven't
> had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
> 
>  -----------------
> 
> The following has been lost from __make_request() in ll_rw_blk.c since
> 2.4.2 (incl):
> 
>  out:
> -       if (!q->plugged)
> -               (q->request_fn)(q);
>         if (freereq)
> 
> The result is that a block device that doesn't do plugging doesn't
> work.
> 
> If it has called blk_queue_pluggable() to register a no-op plug_fn,
> then q->plugged will never be set (it's the duty of the plug_fn), and
> the devices registered request function will never be called.
> 
> This behaviour is distinct from 2.4.0, where registering a no-op
> plug_fn made things work fine.
> 
> Is this a coding oversight?

Check the archives, I replied to this days ago. But since I'm taking the
subject up anyway, let me expand on it a bit further.

Not using plugging is gone, blk_queue_pluggable has been removed from
the current 2.4.4-pre series if you check that. The main reason for
doing this, is that there are generally no reasons for _not_ using
plugging in the 2.4 series kernels. In 2.2 and previous, not using the
builtin plugging was generally done to disable request merging. In 2.4,
the queues have good control over what happens there with the
back/front/request merging functions -- so drivers can just use that.

Besides, the above hunk was removed because it is wrong. For devices
using plugging, we would re-call the request_fn while the device was
already active and serving requests. Not only is this a performance hit
we don't need to take, it also gave problems on some drivers.

-- 
Jens Axboe


  reply	other threads:[~2001-04-19 10:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-19 10:39 block devices don't work without plugging in 2.4.3 Peter T. Breuer
2001-04-19 10:51 ` Jens Axboe [this message]
2001-04-19 11:23   ` Peter T. Breuer
2001-04-19 11:54     ` Jens Axboe
2001-04-19 12:33       ` Peter T. Breuer
2001-04-19 12:40         ` Jens Axboe
2001-04-19 13:09           ` Peter T. Breuer
2001-04-19 13:24             ` Jens Axboe
2001-04-19 13:54               ` Peter T. Breuer
2001-04-19 13:59                 ` Jens Axboe
2001-04-19 14:46                   ` Peter T. Breuer
  -- strict thread matches above, loose matches on Subject: below --
2001-04-17 16:40 Peter T. Breuer
2001-04-17 17:03 ` 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=20010419125140.M16822@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