From: Daniel Phillips <phillips@bonn-fries.net>
To: Christian Smith <csmith@micromuse.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
Joseph A Knapka <jknapka@earthlink.net>,
"Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
linux-mm@kvack.org
Subject: Re: Why *not* rmap, anyway?
Date: Tue, 7 May 2002 21:37:57 +0200 [thread overview]
Message-ID: <E175Ame-0000Tb-00@starship> (raw)
In-Reply-To: <Pine.LNX.4.33.0205071625570.1579-100000@erol>
On Tuesday 07 May 2002 20:37, Christian Smith wrote:
> I can clearly see this is flogging a dead horse, so I'll let it lie, save
> the following observations and comments inline:
> - The Linux VM is very difficult to pick up. Maybe not conceptually, but
> the implementation is a nightmare to follow. That's probably why it's so
> poorly documented.
It's poorly documented because the latest edition of Understanding the Linux
Kernel isn't out yet ;-)
Your best sources of documentation at this point are:
- lxr.linux.no (or source navigator)
- Andrea's slides
- Understanding the Linux Kernel (mostly still applies)
- background links on kernelnewbies.org
> - While rmap is the way to go, it's still more of a band-aid than an
> intergrated solution.
Nope, this would indicate you don't have a handled on the fundamental
algorithms. Switching from virtual scanning to physical scanning is hardly
something you'd describe as a bandaid.
> - do_page_fault() is definately in the wrong place, or at least, the work
> it does (it finds the generic vma of the fault. This should be generic
> code.)
It's per-arch because different architectures have very different sets of
conditions that have to be handled. If you like, you can try to break out
some cross-arch factors and make them into inlines or something. That's
cleanup work that's hard and mostly thankless. We need more gluttons for
punishment^W^W^W volunteers to tackle this kind of thing.
> - Most people appear to be aiming towards absolute speed in all cases,
> without considering the wider picture. Anything that makes choosing the
> correct page to page out will out do any level of code optimisation due
> to the obvious limits to IO speed. Looking at Linux VM performance
> against any of the BSDs and SysV should indicate that a split generic
> VM/pmap layer is easier to optimise for the heavy load conditions, not
> to mention maintain.
The FreeBSD VM is maybe easy to optimise if you are Matt Dillon, but before
he came along it was a disaster.
The Linux VM is pretty much impossible to optimize for large memory machines
in its current form, that is why the move to switch from virtual scanning
to physical scanning. Other than that, it's not too bad.
--
Daniel
(p.s., it's not really necessary to include the entire thread at the bottom
of each post.)
--
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:[~2002-05-07 19:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-21 22:27 Joseph A Knapka
2002-04-22 0:23 ` Martin J. Bligh
2002-04-22 2:13 ` Joseph A Knapka
2002-04-22 5:46 ` Martin J. Bligh
2002-04-23 22:40 ` Christian Smith
2002-04-24 0:46 ` Rik van Riel
2002-04-24 10:50 ` Christian Smith
2002-04-24 14:20 ` Rik van Riel
2002-04-24 14:37 ` Momchil Velikov
2002-04-24 14:52 ` Rik van Riel
2002-04-24 15:16 ` Momchil Velikov
2002-04-24 18:31 ` William Lee Irwin III
2002-04-25 15:19 ` Christian Smith
2002-05-05 19:04 ` Daniel Phillips
2002-05-07 18:37 ` Christian Smith
2002-05-07 19:23 ` Rik van Riel
2002-05-07 19:25 ` William Lee Irwin III
2002-05-07 19:47 ` Daniel Phillips
2002-05-07 19:50 ` William Lee Irwin III
2002-05-07 23:02 ` Daniel Phillips
2002-05-08 0:08 ` William Lee Irwin III
2002-05-08 5:08 ` Andrew Morton
2002-05-08 7:59 ` Momchil Velikov
2002-05-08 14:33 ` Daniel Phillips
2002-05-08 14:43 ` Rik van Riel
2002-05-08 16:06 ` Daniel Phillips
2002-05-08 16:10 ` Rik van Riel
2002-05-07 19:49 ` Rik van Riel
2002-05-07 19:53 ` William Lee Irwin III
2002-05-07 19:43 ` Daniel Phillips
2002-05-07 19:51 ` Rik van Riel
2002-05-07 23:11 ` Daniel Phillips
2002-05-07 21:21 ` William Lee Irwin III
2002-05-07 23:15 ` Daniel Phillips
2002-05-07 19:37 ` Daniel Phillips [this message]
2002-05-07 19:47 ` William Lee Irwin III
2002-05-05 18:38 ` Daniel Phillips
2002-05-05 22:23 ` Rik van Riel
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=E175Ame-0000Tb-00@starship \
--to=phillips@bonn-fries.net \
--cc=Martin.Bligh@us.ibm.com \
--cc=csmith@micromuse.com \
--cc=jknapka@earthlink.net \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/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