From: Chris Mason <mason@suse.com>
To: Daniel Phillips <phillips@bonn-fries.net>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Subject: Re: [RFC] using writepage to start io
Date: Tue, 07 Aug 2001 11:19:13 -0400 [thread overview]
Message-ID: <75850000.997197553@tiny> (raw)
On Monday, August 06, 2001 11:18:26 PM +0200 Daniel Phillips
<phillips@bonn-fries.net> wrote:
>> Grin, we're talking in circles. My point is that by having two
>> threads, bdflush is allowed to skip over older buffers in favor of
>> younger ones because somebody else is responsible for writing the
>> older ones out.
>
> Yes, and you can't imagine an algorithm that could do that with *one*
> thread?
Imagine one? Yes. We're mixing a bunch of issues, so I'll list the 3
different cases again. memory pressure, write throttling, age limiting.
Pretending that a single thread could get enough context information about
which of the 3 (perhaps more than one) it is currently facing, it can make
the right decisions.
The problem with that right now is that a single thread can't keep up (with
one case, let alone all 3) as the number of devices increases. We can more
or less just replay the entire l-k discussion(s) on threading models here.
In my mind, in order for a single thread to get the job done, it can't end
up waiting on a device while there are still buffers ready for writeout to
idle devices.
As for a generic mechanism to schedule all FS writeback, I've been trying
to use writepage ;-) The bad part here it makes the async issues even
bigger, since the flushing thread ends up calling into the FS (who knows
what that might lead to).
-chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <mason@suse.com>
To: Daniel Phillips <phillips@bonn-fries.net>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Subject: Re: [RFC] using writepage to start io
Date: Tue, 07 Aug 2001 11:19:13 -0400 [thread overview]
Message-ID: <75850000.997197553@tiny> (raw)
On Monday, August 06, 2001 11:18:26 PM +0200 Daniel Phillips
<phillips@bonn-fries.net> wrote:
>> Grin, we're talking in circles. My point is that by having two
>> threads, bdflush is allowed to skip over older buffers in favor of
>> younger ones because somebody else is responsible for writing the
>> older ones out.
>
> Yes, and you can't imagine an algorithm that could do that with *one*
> thread?
Imagine one? Yes. We're mixing a bunch of issues, so I'll list the 3
different cases again. memory pressure, write throttling, age limiting.
Pretending that a single thread could get enough context information about
which of the 3 (perhaps more than one) it is currently facing, it can make
the right decisions.
The problem with that right now is that a single thread can't keep up (with
one case, let alone all 3) as the number of devices increases. We can more
or less just replay the entire l-k discussion(s) on threading models here.
In my mind, in order for a single thread to get the job done, it can't end
up waiting on a device while there are still buffers ready for writeout to
idle devices.
As for a generic mechanism to schedule all FS writeback, I've been trying
to use writepage ;-) The bad part here it makes the async issues even
bigger, since the flushing thread ends up calling into the FS (who knows
what that might lead to).
-chris
--
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 reply other threads:[~2001-08-07 15:19 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-07 15:19 Chris Mason [this message]
2001-08-07 15:19 ` [RFC] using writepage to start io Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2001-08-05 18:34 Chris Mason
2001-08-05 18:34 ` Chris Mason
2001-08-05 22:38 ` Daniel Phillips
2001-08-05 22:38 ` Daniel Phillips
2001-08-05 23:32 ` Chris Mason
2001-08-05 23:32 ` Chris Mason
2001-08-06 5:39 ` Daniel Phillips
2001-08-06 5:39 ` Daniel Phillips
2001-08-06 13:24 ` Chris Mason
2001-08-06 13:24 ` Chris Mason
2001-08-06 16:13 ` Daniel Phillips
2001-08-06 16:13 ` Daniel Phillips
2001-08-06 16:51 ` Chris Mason
2001-08-06 16:51 ` Chris Mason
2001-08-06 19:45 ` Daniel Phillips
2001-08-06 19:45 ` Daniel Phillips
2001-08-06 20:12 ` Chris Mason
2001-08-06 20:12 ` Chris Mason
2001-08-06 21:18 ` Daniel Phillips
2001-08-06 21:18 ` Daniel Phillips
2001-08-07 11:02 ` Stephen C. Tweedie
2001-08-07 11:02 ` Stephen C. Tweedie
2001-08-07 11:39 ` Ed Tomlinson
2001-08-07 11:39 ` Ed Tomlinson
2001-08-07 18:36 ` Daniel Phillips
2001-08-07 18:36 ` Daniel Phillips
2001-08-07 12:07 ` Anton Altaparmakov
2001-08-07 12:07 ` Anton Altaparmakov
2001-08-07 12:02 ` Anton Altaparmakov
2001-08-07 12:02 ` Anton Altaparmakov
2001-08-07 13:29 ` Daniel Phillips
2001-08-07 13:29 ` Daniel Phillips
2001-08-07 13:31 ` Alexander Viro
2001-08-07 13:31 ` Alexander Viro
2001-08-07 15:52 ` Daniel Phillips
2001-08-07 15:52 ` Daniel Phillips
2001-08-07 14:23 ` Stephen C. Tweedie
2001-08-07 14:23 ` Stephen C. Tweedie
2001-08-07 15:51 ` Daniel Phillips
2001-08-07 15:51 ` Daniel Phillips
2001-08-08 14:49 ` Stephen C. Tweedie
2001-08-08 14:49 ` Stephen C. Tweedie
2001-08-06 15:13 ` Eric W. Biederman
2001-08-06 15:13 ` Eric W. Biederman
2001-07-28 16:01 Chris Mason
2001-07-28 16:18 ` Alexander Viro
2001-07-28 16:25 ` Chris Mason
2001-07-31 19:07 ` Chris Mason
2001-07-31 19:07 ` Chris Mason
2001-08-01 1:01 ` Daniel Phillips
2001-08-01 1:01 ` Daniel Phillips
2001-08-01 2:05 ` Chris Mason
2001-08-01 2:05 ` Chris Mason
2001-08-01 14:57 ` Daniel Phillips
2001-08-01 14:57 ` Daniel Phillips
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=75850000.997197553@tiny \
--to=mason@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=phillips@bonn-fries.net \
/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.