From: Andrea Arcangeli <andrea@suse.de>
To: Nick Piggin <piggin@cyberone.com.au>
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 05:33:42 +0200 [thread overview]
Message-ID: <20030612033342.GC1571@dualathlon.random> (raw)
In-Reply-To: <3EE7F18C.3010502@cyberone.com.au>
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 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.
> 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).
Andrea
next prev parent reply other threads:[~2003-06-12 3:19 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 [this message]
2003-06-12 3:48 ` Nick Piggin
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=20030612033342.GC1571@dualathlon.random \
--to=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 \
--cc=piggin@cyberone.com.au \
/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