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 15:59:30 +0200	[thread overview]
Message-ID: <20010419155930.G22517@suse.de> (raw)
In-Reply-To: <20010419152443.B22517@suse.de> <200104191354.f3JDs7C27006@oboe.it.uc3m.es>
In-Reply-To: <200104191354.f3JDs7C27006@oboe.it.uc3m.es>; from ptb@it.uc3m.es on Thu, Apr 19, 2001 at 03:54:07PM +0200

On Thu, Apr 19 2001, Peter T. Breuer wrote:
> OK - agreed. But while I have your attention...
> 
> "Jens Axboe wrote:"
> > On the contrary, you are now given an exceptional opportunity to clean
> > up your code and get rid of blk_queue_pluggable and your noop plugging
> > function.
> 
> In summary: blk_queue_pluggable can be removed for all driver codes
> aimed at all 2.4.* kernels, because the intended effect can be obtained
> through merge_reqeusts function controls.

Yes

> My unease derives, I think, from the fact that I have occasionally used
> plugging for other purposes. Namely for throttling the device. These
> uses have always been experimental and uniformly unsuccessful, because
> throttling that way backs up the VFS with dirty buffers and provokes
> precisely the deadlock against VFS that I was trying to avoid. So ..
> 
>  ... how can I tell when VFS is nearly full?  In those circumstances I
> want to sync every _other_ device, thus giving me enough buffers at
> least to flush something to the net with, thus freeing a request of
> mine, plus its buffers.

You can't, there's currently no way of doing what you suggest. The block
layer will throttle locked buffers for you. Besides, this would be the
very wrong place to do it. If you reject or throttle requests, you are
effectively throttling stuff that is already locked down and cannot be
touched.

-- 
Jens Axboe


  reply	other threads:[~2001-04-19 14:00 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
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 [this message]
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=20010419155930.G22517@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