From: Linus Torvalds <torvalds@transmeta.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>, Rik van Riel <riel@conectiva.com.br>,
MM mailing list <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:32:27 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.10.10010021630390.4306-100000@penguin.transmeta.com> (raw)
In-Reply-To: <20001003012546.C27493@athlon.random>
On Tue, 3 Oct 2000, Andrea Arcangeli wrote:
> On Tue, Oct 03, 2000 at 01:29:27AM +0200, Ingo Molnar wrote:
> > it can and does lose them - but only all of them. Aging OTOH is a per-bh
> > thing, this kind of granularity is simply not present in the current
> > page->buffers handling. This is all i wanted to mention. Not unsolvable,
>
> I'm pretty sure it doesn't worth the per-bh thing. And even if it would make
> any difference with a 1k fs for good performance 4k blksize is necessary anyway
> for other reasons.
Well, remember that some page sizes are large. A page size is not
necessarily 4k. It could be 64k.
Now, you're probably right that if you want to perform well, a 64k block
is not that large, and most things that do ordered writes might not be too
badly off with even that kind of big ordering granularity. But let's not
take it for granted.
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/
next prev parent reply other threads:[~2000-10-02 23:32 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
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 [this message]
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.10010021630390.4306-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