From: "David S. Miller" <davem@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
linux-mm@kvack.org, "Stephen C. Tweedie" <sct@redhat.com>,
Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: [RFC] 2-pointer PTE chaining idea
Date: Fri, 19 Jan 2001 21:31:04 -0800 (PST) [thread overview]
Message-ID: <14953.8856.982405.328564@pizda.ninka.net> (raw)
In-Reply-To: <Pine.LNX.4.10.10101192108150.2760-100000@penguin.transmeta.com>
Linus Torvalds writes:
> - DO NOT WASTE TIME IF YOU HAVE MEMORY!
>
> The second point is important. You have to really think about how Linux
> handles anonymous pages, and understand that that is not just an accident.
> It's really important to NOT do extra work for the case where an
> application just wants a page. Don't allocate swap backing store early.
> Don't add it to the page cache if it doesn't need to be there. Don't do
> ANYTHING.
>
> This, btw, also implies: don't make the page tables more complex.
I have to concur. The more I think about the whole idea of
pte-chaining the more I dislike it and think work on it is a waste of
time. I can say this, being that I actually tried once to fully make
such a scheme work.
My old gripe and incentive to do such things has honestly
disappeared. The big issue was cache aliasing problems on
some silly cpus, but the current recommented APIs described
in Documentation/cachetlb.txt can handle such situations quite
acceptably.
Basically, that would leave us with the issue of choosing anonymous
pages to tap out correctly. I see nothing that prevents our page
table scanning from being fundamentally unable to do quite well in
this area. Sure, true LRU aging of anonymous pages alongside all the
other reclaimable pages in the system is not possible now, but I
cannot provably show that this is actually required for good behavior.
-DaveM
--
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:[~2001-01-20 5:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-19 5:08 Rik van Riel
2001-01-19 6:57 ` David S. Miller
2001-01-19 7:17 ` Linus Torvalds
2001-01-19 7:55 ` Rik van Riel
2001-01-20 5:22 ` Linus Torvalds
2001-01-20 5:31 ` David S. Miller [this message]
2001-01-20 7:05 ` Rik van Riel
2001-01-19 11:49 ` Ingo Molnar
2001-01-20 6:58 ` Rik van Riel
2001-01-19 11:37 ` 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=14953.8856.982405.328564@pizda.ninka.net \
--to=davem@redhat.com \
--cc=dillon@apollo.backplane.com \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.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