public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: bill davidsen <davidsen@tmr.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: IO scheduler, queue depth, nr_requests
Date: Thu, 26 Feb 2004 11:39:17 +1100	[thread overview]
Message-ID: <403D4035.1010208@cyberone.com.au> (raw)
In-Reply-To: <403D02E3.4070208@tmr.com>



Bill Davidsen wrote:

> linux.kernelNick Piggin wrote:
>
>> But the whole reason it is getting blocked in the first place
>> is because your controller is sucking up all your requests.
>> The whole problem is not a problem if you use properly sized
>> queues.
>>
>> I'm a bit surprised that it wasn't working well with a controller
>> queue depth of 64 and 128 nr_requests. I'll give you a per process
>> request limit patch to try in a minute.
>
>
> And there's the rub... he did try what you are calling correctly sized 
> queues, and his patch works better. I'm all in favor of having the 
> theory and then writing the code, but when something works I would 
> rather understand why and modify the theory.
>
> In other words, given a patch which does help performance in this 
> case, it would be good to understand why, instead of favoring a 
> solution which is better in theory, but which has been tried and found 
> inferior in performance.
>
> I am NOT saying we should just block, effective as Miquel's patch 
> seems, just that we should understand why it works well instead of 
> saying it is in theory bad. I agree, but it works! Hopefully 
> per-process limits solve this, but they "in theory" could result in 
> blocking a process in an otherwise idle system. Unless I midread what 
> you mean of course. Processes which calculate for a while and write 
> results are not uncomon, and letting such a process write a whole 
> bunch of data and then go calculate while it is written is certainly 
> the way it should work. I'm unconvinced that per-process limits are 
> the whole answer without considering the entire io load on the system.
>
> Feel free to tell me I'm misreading your intent (and why).


No, I know Miquel's patch works and his analysis of what is happening
is correct (he proved it). The patch is a bit of a hack to get around
the specific problem he is seeing which should never happen with an
appropriately sized queue, and it might actually hurt in some cases.


  parent reply	other threads:[~2004-02-26  0:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1qJVx-75K-15@gated-at.bofh.it>
     [not found] ` <1qJVx-75K-17@gated-at.bofh.it>
     [not found]   ` <1qJVw-75K-11@gated-at.bofh.it>
     [not found]     ` <1qLb8-6m-27@gated-at.bofh.it>
     [not found]       ` <1qLXl-XV-17@gated-at.bofh.it>
     [not found]         ` <1qMgF-1dA-5@gated-at.bofh.it>
     [not found]           ` <1qTs3-7A2-51@gated-at.bofh.it>
     [not found]             ` <1qTBB-7Hh-7@gated-at.bofh.it>
     [not found]               ` <1r3AS-1hW-5@gated-at.bofh.it>
     [not found]                 ` <1r5jD-2RQ-31@gated-at.bofh.it>
     [not found]                   ` <1r6fH-3L8-11@gated-at.bofh.it>
     [not found]                     ` <1r6S4-6cv-1@gated-at.bofh.it>
2004-02-25 20:17                       ` IO scheduler, queue depth, nr_requests Bill Davidsen
2004-02-25 21:39                         ` Miquel van Smoorenburg
2004-02-26  0:39                         ` Nick Piggin [this message]
     [not found] <20040216131609.GA21974@cistron.nl>
     [not found] ` <20040216133047.GA9330@suse.de>
     [not found]   ` <20040217145716.GE30438@traveler.cistron.net>
2004-02-18 23:52     ` Miquel van Smoorenburg
2004-02-19  1:24       ` Nick Piggin
2004-02-19  1:52         ` Miquel van Smoorenburg
2004-02-19  2:01           ` Nick Piggin
2004-02-19  1:26       ` Andrew Morton
2004-02-19  2:11         ` Miquel van Smoorenburg
2004-02-19  2:26           ` Andrew Morton
2004-02-19 10:15             ` Miquel van Smoorenburg
2004-02-19 10:19               ` Jens Axboe
2004-02-19 20:59                 ` Miquel van Smoorenburg
2004-02-19 22:52                   ` Nick Piggin
2004-02-19 23:53                     ` Miquel van Smoorenburg
2004-02-20  0:15                       ` Nick Piggin
2004-02-19  2:51           ` Nick Piggin
2004-02-19 10:21             ` 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=403D4035.1010208@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=davidsen@tmr.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