From: Nick Piggin <piggin@cyberone.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Chris Mason <mason@suse.com>,
Marc-Christian Petersen <m.c.p@wolk-project.de>,
Jens Axboe <axboe@suse.de>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
Georg Nikodym <georgn@somanetworks.com>,
lkml <linux-kernel@vger.kernel.org>,
Matthias Mueller <matthias.mueller@rz.uni-karlsruhe.de>
Subject: Re: [PATCH] io stalls
Date: Thu, 12 Jun 2003 13:48:04 +1000 [thread overview]
Message-ID: <3EE7F7F4.1040800@cyberone.com.au> (raw)
In-Reply-To: <20030612033342.GC1571@dualathlon.random>
Andrea Arcangeli wrote:
>On Thu, Jun 12, 2003 at 01:20:44PM +1000, Nick Piggin wrote:
>
>>Its no less fair this way, tasks will still be woken in fifo
>>order. They will just be given the chance to submit a batch
>>of requests.
>>
>
>If you change the behaviour with queued_task_nr > batch_requests it is
>less fair period. Whatever else thing I don't care about right now
>because it is a minor cpu improvement anyways.
>
>I'm not talking about performance, I'm talking about latency and
>fariness only. This is the whole point of the ->full logic.
>
I say each task getting 8 requests at a time is as fair
as each getting 1 request at a time. Yes, you may get a
worse latency, but _fairness_ is the same.
>
>>I think the cpu utilization gain of waking a number of tasks
>>at once would be outweighed by advantage of waking 1 task
>>and not putting it to sleep again for a number of requests.
>>You obviously are not claiming concurrency improvements, as
>>your method would also increase contention on the io lock
>>(or the queue lock in 2.5).
>>
>
>I'm claiming that with queued_task_nr > batch_requests the
>batch_requests logic still has a chance to save some cpu, this is the
>only reason I didn't nuke it completely as you suggested some email ago.
>
Well I'm not so sure that your method will do a great deal
of good. On SMP you would increase contention on the spinlock.
IMO it would be better to serialise them on the waitqueue
instead of a spinlock seeing as they are already sleeping.
>
>>Then you have the cache gains of running each task for a
>>longer period of time. You also get possible IO scheduling
>>improvements.
>>
>>Consider 8 requests, batch_requests at 4, 10 tasks writing
>>to different areas of disk.
>>
>>Your method still only allows each task to have 1 request in
>>the elevator at once. Mine allows each to have a run of 4
>>requests in the elevator.
>>
>
>I definitely want 1 request in the elevator at once or we can as well
>drop your ->full and return to be unfair. The whole point of ->full is
>to get the total fariness, across the tasks in the queue queue, and for
>tasks outside the queue calling get_request too. Since not all tasks
>will fit in the I/O queue, providing a very fair FIFO in the
>wait_for_request is fundamental to provide any sort of latency
>guarantee IMHO (the fact an _exclusive wakeup removal that mixes stuff
>and probably has the side effect of being more fair, made that much
>difference to mainline users kind of confirms that).
>
>
I think we'll just have to agree to disagree here. This
sort of thing came up in our CFQ discussion as well. Its
not that I think your way is without merits, but I think
in an overload situtation its a better aim to attempt to
keep throughput up rather than attempt to provide the
lowest possible latency.
next prev parent reply other threads:[~2003-06-12 3:34 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-29 0:55 Linux 2.4.21-rc6 Marcelo Tosatti
2003-05-29 1:22 ` Con Kolivas
2003-05-29 5:24 ` Marc Wilson
2003-05-29 5:34 ` Riley Williams
2003-05-29 5:57 ` Marc Wilson
2003-05-29 7:15 ` Riley Williams
2003-05-29 8:38 ` Willy Tarreau
2003-05-29 8:40 ` Willy Tarreau
2003-06-03 16:02 ` Marcelo Tosatti
2003-06-03 16:13 ` Marc-Christian Petersen
2003-06-04 21:54 ` Pavel Machek
2003-06-05 2:10 ` Michael Frank
2003-06-03 16:30 ` Michael Frank
2003-06-03 16:53 ` Matthias Mueller
2003-06-03 16:59 ` Marc-Christian Petersen
2003-06-03 17:03 ` Marc-Christian Petersen
2003-06-03 18:02 ` Anders Karlsson
2003-06-03 21:12 ` J.A. Magallon
2003-06-03 21:18 ` Marc-Christian Petersen
2003-06-03 17:23 ` Michael Frank
2003-06-04 14:56 ` Jakob Oestergaard
2003-06-04 4:04 ` Marc Wilson
2003-05-29 10:02 ` Con Kolivas
2003-05-29 18:00 ` Georg Nikodym
2003-05-29 19:11 ` -rc7 " Marcelo Tosatti
2003-05-29 19:56 ` Krzysiek Taraszka
2003-05-29 20:18 ` Krzysiek Taraszka
2003-06-04 18:17 ` Marcelo Tosatti
2003-06-04 21:41 ` Krzysiek Taraszka
2003-06-04 22:37 ` Alan Cox
2003-06-04 10:22 ` Andrea Arcangeli
2003-06-04 10:35 ` Marc-Christian Petersen
2003-06-04 10:42 ` Jens Axboe
2003-06-04 10:46 ` Marc-Christian Petersen
2003-06-04 10:48 ` Andrea Arcangeli
2003-06-04 11:57 ` Nick Piggin
2003-06-04 12:00 ` Jens Axboe
2003-06-04 12:09 ` Andrea Arcangeli
2003-06-04 12:20 ` Jens Axboe
2003-06-04 20:50 ` Rob Landley
2003-06-04 12:11 ` Nick Piggin
2003-06-04 12:35 ` Miquel van Smoorenburg
2003-06-09 21:39 ` [PATCH] io stalls (was: -rc7 Re: Linux 2.4.21-rc6) Chris Mason
2003-06-09 22:19 ` Andrea Arcangeli
2003-06-10 0:27 ` Chris Mason
2003-06-10 23:13 ` Chris Mason
2003-06-11 0:16 ` Andrea Arcangeli
2003-06-11 0:44 ` Chris Mason
2003-06-09 23:51 ` [PATCH] io stalls Nick Piggin
2003-06-10 0:32 ` Chris Mason
2003-06-10 0:47 ` Nick Piggin
2003-06-10 1:48 ` Robert White
2003-06-10 2:13 ` Chris Mason
2003-06-10 23:04 ` Robert White
2003-06-11 0:58 ` Chris Mason
2003-06-10 3:22 ` Nick Piggin
2003-06-10 21:17 ` Robert White
2003-06-11 0:40 ` Nick Piggin
2003-06-11 0:33 ` [PATCH] io stalls (was: -rc7 Re: Linux 2.4.21-rc6) Andrea Arcangeli
2003-06-11 0:48 ` [PATCH] io stalls Nick Piggin
2003-06-11 1:07 ` Andrea Arcangeli
2003-06-11 0:54 ` [PATCH] io stalls (was: -rc7 Re: Linux 2.4.21-rc6) Chris Mason
2003-06-11 1:06 ` Andrea Arcangeli
2003-06-11 1:57 ` Chris Mason
2003-06-11 2:10 ` Andrea Arcangeli
2003-06-11 12:24 ` Chris Mason
2003-06-11 17:42 ` Chris Mason
2003-06-11 18:12 ` Andrea Arcangeli
2003-06-11 18:27 ` Chris Mason
2003-06-11 18:35 ` Andrea Arcangeli
2003-06-12 1:04 ` [PATCH] io stalls Nick Piggin
2003-06-12 1:12 ` Chris Mason
2003-06-12 1:29 ` Andrea Arcangeli
2003-06-12 1:37 ` Andrea Arcangeli
2003-06-12 2:22 ` Chris Mason
2003-06-12 2:41 ` Nick Piggin
2003-06-12 2:46 ` Andrea Arcangeli
2003-06-12 2:49 ` Nick Piggin
2003-06-12 2:51 ` Nick Piggin
2003-06-12 2:52 ` Nick Piggin
2003-06-12 3:04 ` Andrea Arcangeli
2003-06-12 2:58 ` Andrea Arcangeli
2003-06-12 3:04 ` Nick Piggin
2003-06-12 3:12 ` Andrea Arcangeli
2003-06-12 3:20 ` Nick Piggin
2003-06-12 3:33 ` Andrea Arcangeli
2003-06-12 3:48 ` Nick Piggin [this message]
2003-06-12 4:17 ` Andrea Arcangeli
2003-06-12 4:41 ` Nick Piggin
2003-06-12 16:06 ` Chris Mason
2003-06-12 16:16 ` Nick Piggin
2003-06-25 19:03 ` Chris Mason
2003-06-25 19:25 ` Andrea Arcangeli
2003-06-25 20:18 ` Chris Mason
2003-06-27 8:41 ` write-caches, I/O stalls: MUST-FIX (was: [PATCH] io stalls) Matthias Andree
2003-06-26 5:48 ` [PATCH] io stalls Nick Piggin
2003-06-26 11:48 ` Chris Mason
2003-06-26 13:04 ` Nick Piggin
2003-06-26 13:18 ` Nick Piggin
2003-06-26 15:55 ` Chris Mason
2003-06-27 1:21 ` Nick Piggin
2003-06-27 1:39 ` Chris Mason
2003-06-27 9:45 ` Nick Piggin
2003-06-27 12:41 ` Chris Mason
2003-06-12 11:57 ` Chris Mason
2003-06-04 10:43 ` -rc7 Re: Linux 2.4.21-rc6 Andrea Arcangeli
2003-06-04 11:01 ` Marc-Christian Petersen
2003-06-03 19:45 ` Config issue (CONFIG_X86_TSC) " Paul
2003-06-03 20:18 ` Jan-Benedict Glaw
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=3EE7F7F4.1040800@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=georgn@somanetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.c.p@wolk-project.de \
--cc=marcelo@conectiva.com.br \
--cc=mason@suse.com \
--cc=matthias.mueller@rz.uni-karlsruhe.de \
/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;
as well as URLs for NNTP newsgroup(s).