From: Nick Piggin <piggin@cyberone.com.au>
To: Giuliano Pochini <pochini@shiny.it>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-kernel@alex.org.uk, Alex Tomas <bzzz@tmi.comex.ru>,
Andrew Morton <akpm@digeo.com>,
Oliver Xymoron <oxymoron@waste.org>
Subject: Re: 2.5.59-mm5
Date: Sat, 25 Jan 2003 04:22:39 +1100 [thread overview]
Message-ID: <3E31765F.4010900@cyberone.com.au> (raw)
In-Reply-To: XFMail.20030124180942.pochini@shiny.it
Giuliano Pochini wrote:
>>>An alternate approach might be to change the way the scheduler splits
>>>things. That is, rather than marking I/O read vs write and scheduling
>>>based on that, add a flag bit to mark them all sync vs async since
>>>that's the distinction we actually care about. The normal paths can
>>>all do read+sync and write+async, but you can now do things like
>>>marking your truncate writes sync and readahead async.
>>>
>
>>That will be worth investigating to see if the complexity is worth it.
>>I think from a disk point of view, we still want to split batches between
>>reads and writes. Could be wrong.
>>
>
>Yes, sync vs async is a better way to classify io requests than
>read vs write and it's more correct from OS point of view. IMHO
>it's not more complex then now. Just replace r/w with sy/as and
>it will work.
>
We probably wouldn't want to go that far as you obviously can
only merge reads with reads and writes with writes, a flag would
be fine. We have to get the basics working first though ;)
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <piggin@cyberone.com.au>
To: Giuliano Pochini <pochini@shiny.it>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-kernel@alex.org.uk, Alex Tomas <bzzz@tmi.comex.ru>,
Andrew Morton <akpm@digeo.com>,
Oliver Xymoron <oxymoron@waste.org>
Subject: Re: 2.5.59-mm5
Date: Sat, 25 Jan 2003 04:22:39 +1100 [thread overview]
Message-ID: <3E31765F.4010900@cyberone.com.au> (raw)
In-Reply-To: XFMail.20030124180942.pochini@shiny.it
Giuliano Pochini wrote:
>>>An alternate approach might be to change the way the scheduler splits
>>>things. That is, rather than marking I/O read vs write and scheduling
>>>based on that, add a flag bit to mark them all sync vs async since
>>>that's the distinction we actually care about. The normal paths can
>>>all do read+sync and write+async, but you can now do things like
>>>marking your truncate writes sync and readahead async.
>>>
>
>>That will be worth investigating to see if the complexity is worth it.
>>I think from a disk point of view, we still want to split batches between
>>reads and writes. Could be wrong.
>>
>
>Yes, sync vs async is a better way to classify io requests than
>read vs write and it's more correct from OS point of view. IMHO
>it's not more complex then now. Just replace r/w with sy/as and
>it will work.
>
We probably wouldn't want to go that far as you obviously can
only merge reads with reads and writes with writes, a flag would
be fine. We have to get the basics working first though ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2003-01-24 17:13 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-24 3:50 2.5.59-mm5 Andrew Morton
2003-01-24 3:50 ` 2.5.59-mm5 Andrew Morton
2003-01-24 11:03 ` 2.5.59-mm5 Alex Bligh - linux-kernel
2003-01-24 11:03 ` 2.5.59-mm5 Alex Bligh - linux-kernel
2003-01-24 11:16 ` 2.5.59-mm5 Andrew Morton
2003-01-24 11:16 ` 2.5.59-mm5 Andrew Morton
2003-01-24 11:23 ` 2.5.59-mm5 Alex Tomas
2003-01-24 11:23 ` 2.5.59-mm5 Alex Tomas
2003-01-24 11:50 ` 2.5.59-mm5 Andrew Morton
2003-01-24 11:50 ` 2.5.59-mm5 Andrew Morton
2003-01-24 12:05 ` 2.5.59-mm5 Alex Tomas
2003-01-24 12:05 ` 2.5.59-mm5 Alex Tomas
2003-01-24 19:12 ` 2.5.59-mm5 Andrew Morton
2003-01-24 19:12 ` 2.5.59-mm5 Andrew Morton
2003-01-24 19:58 ` 2.5.59-mm5 Alex Tomas
2003-01-24 19:58 ` 2.5.59-mm5 Alex Tomas
2003-01-25 17:32 ` 2.5.59-mm5 Ed Tomlinson
2003-01-25 17:41 ` 2.5.59-mm5 Andrew Morton
2003-01-25 20:34 ` 2.5.59-mm5 Ed Tomlinson
2003-01-25 22:33 ` 2.5.59-mm5 Andrew Morton
2003-01-26 1:43 ` 2.5.59-mm5 Ed Tomlinson
2003-01-26 2:17 ` 2.5.59-mm5 Andrew Morton
2003-01-26 3:51 ` 2.5.59-mm5 Ed Tomlinson
2003-01-26 4:04 ` 2.5.59-mm5 Andrew Morton
2003-01-24 15:56 ` 2.5.59-mm5 Oliver Xymoron
2003-01-24 15:56 ` 2.5.59-mm5 Oliver Xymoron
2003-01-24 16:04 ` 2.5.59-mm5 Nick Piggin
2003-01-24 16:04 ` 2.5.59-mm5 Nick Piggin
2003-01-24 17:09 ` 2.5.59-mm5 Giuliano Pochini
2003-01-24 17:09 ` 2.5.59-mm5 Giuliano Pochini
2003-01-24 17:22 ` Nick Piggin [this message]
2003-01-24 17:22 ` 2.5.59-mm5 Nick Piggin
2003-01-24 19:34 ` 2.5.59-mm5 Valdis.Kletnieks
2003-01-24 20:04 ` 2.5.59-mm5 Jens Axboe
2003-01-24 20:04 ` 2.5.59-mm5 Jens Axboe
2003-01-24 22:02 ` 2.5.59-mm5 Valdis.Kletnieks
2003-01-25 12:28 ` 2.5.59-mm5 Jens Axboe
2003-01-25 12:28 ` 2.5.59-mm5 Jens Axboe
2003-01-24 12:14 ` 2.5.59-mm5 Nikita Danilov
2003-01-24 12:14 ` 2.5.59-mm5 Nikita Danilov
2003-01-24 16:00 ` 2.5.59-mm5 Nick Piggin
2003-01-24 16:00 ` 2.5.59-mm5 Nick Piggin
2003-01-24 11:23 ` 2.5.59-mm5 Jens Axboe
2003-01-24 11:23 ` 2.5.59-mm5 Jens Axboe
2003-01-24 13:59 ` 2.5.59-mm5 got stuck during boot Helge Hafting
2003-01-24 13:59 ` Helge Hafting
2003-01-24 17:44 ` Ed Tomlinson
2003-01-24 17:56 ` Nick Piggin
2003-01-24 19:18 ` Ed Tomlinson
2003-01-24 16:17 ` 2.5.59-mm5 jlnance
2003-01-24 19:05 ` 2.5.59-mm5 Andrew Morton
2003-01-25 8:33 ` 2.5.59-mm5 Andres Salomon
2003-01-25 8:33 ` 2.5.59-mm5 Andres Salomon
-- strict thread matches above, loose matches on Subject: below --
2003-01-24 16:59 2.5.59-mm5 Luck, Tony
2003-01-24 21:31 ` 2.5.59-mm5 Andrew Morton
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=3E31765F.4010900@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=akpm@digeo.com \
--cc=bzzz@tmi.comex.ru \
--cc=linux-kernel@alex.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oxymoron@waste.org \
--cc=pochini@shiny.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.