linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Rik van Riel <riel@conectiva.com.br>, Ingo Molnar <mingo@elte.hu>,
	linux-mm@kvack.org, "Stephen C. Tweedie" <sct@redhat.com>
Subject: Re: [highmem bug report against -test5 and -test6] Re: [PATCH] Re: simple FS application that hangs 2.4-test5, mem mgmt problem or FS buffer cache mgmt problem? (fwd)
Date: Mon, 2 Oct 2000 16:06:25 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.10010021559120.2206-100000@penguin.transmeta.com> (raw)
In-Reply-To: <20001003001834.A25467@athlon.random>


On Tue, 3 Oct 2000, Andrea Arcangeli wrote:

> On Mon, Oct 02, 2000 at 07:08:20PM -0300, Rik van Riel wrote:
> > Yes it has. The write order in flush_dirty_buffers() is the order
> > in which the pages were written. This may be different from the
> > LRU order and could give us slightly better IO performance.
> 
> And it will forbid us to use barriers in software elevator and in SCSI hardware
> to avoid having to wait I/O completation every time a journaling fs needs to do
> ordered writes. The write ordering must remain irrelevant to the page-LRU
> order.

Note that ordered writes are going to change how we do things _anyway_,
regardless of whether we have flush_dirty_buffers() or use the LRU list.

So that's a non-argument: neither of the two routines can handle ordered
writes at this point.

You could argue that the simple single ordered queue that is currently in
use by flush_dirty_buffers() might be easier to adopt to ordering. 

I can tell you already that you'd be wrong to argue that. Exactly because
of the fact that we _need_ the page-oriented flushing regardless of what
we do. So we need to solve the page case anyway. Which means that it will
obviously be easiest to solve just _one_ problem (the page case) than to
solve two problems (the page case _and_ the flush_dirty_buffers() case).

Basically the ordered write case will need extra logic, and we might as
well put the effort in just one place anyway. Note that the page case
isn't necessarily any harder in the end - the simple solution might be
something like just adding a generation count to the buffer head, and
having try_to_free_buffers() just refuse to write stuff out before that
generation has come to pass.

			Linus

--
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.eu.org/Linux-MM/

  parent reply	other threads:[~2000-10-02 23:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-02 19:35 Rik van Riel
2000-10-02 19:56 ` Andrea Arcangeli
2000-10-02 19:59   ` Rik van Riel
2000-10-02 20:17     ` Andrea Arcangeli
2000-10-02 20:24       ` Rik van Riel
2000-10-02 21:16     ` Linus Torvalds
2000-10-02 20:06   ` Linus Torvalds
2000-10-02 20:16     ` Rik van Riel
2000-10-02 20:25     ` Ingo Molnar
2000-10-02 20:45       ` Rik van Riel
2000-10-02 21:21         ` Linus Torvalds
2000-10-02 21:27           ` Rik van Riel
2000-10-02 21:19       ` Linus Torvalds
2000-10-02 21:23         ` Rik van Riel
2000-10-02 21:31           ` Linus Torvalds
2000-10-02 21:42             ` Rik van Riel
2000-10-02 21:58               ` Linus Torvalds
2000-10-02 22:08                 ` Rik van Riel
2000-10-02 22:18                   ` Andrea Arcangeli
2000-10-02 22:23                     ` Rik van Riel
2000-10-02 23:06                     ` Linus Torvalds [this message]
2000-10-02 23:12                       ` Rik van Riel
2000-10-02 23:16                         ` Linus Torvalds
2000-10-02 23:20                       ` Andrea Arcangeli
2000-10-02 22:53                   ` Linus Torvalds
2000-10-02 23:06                     ` Rik van Riel
2000-10-02 23:14                       ` Linus Torvalds
2000-10-02 21:57         ` Ingo Molnar
2000-10-02 21:52           ` Rik van Riel
2000-10-02 22:53             ` Ingo Molnar
2000-10-02 23:01               ` Rik van Riel
2000-10-02 23:10                 ` Andrea Arcangeli
2000-10-02 23:29                 ` Ingo Molnar
2000-10-02 23:25                   ` Andrea Arcangeli
2000-10-02 23:32                     ` Linus Torvalds
2000-10-03 12:05                     ` Ingo Molnar

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=Pine.LNX.4.10.10010021559120.2206-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=andrea@suse.de \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.com \
    /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