From: Rik van Riel <riel@redhat.com>
To: John Stoffel <john@stoffel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Lee Schermerhorn <lee.schermerhorn@hp.com>,
linux-kernel@vger.kernel.org, kosaki.motohiro@jp.fujitsu.com,
eric.whitney@hp.com, linux-mm@kvack.org, npiggin@suse.de
Subject: Re: [PATCH 00/25] Vm Pageout Scalability Improvements (V8) - continued
Date: Fri, 30 May 2008 10:29:17 -0400 [thread overview]
Message-ID: <20080530102917.45cbca64@bree.surriel.com> (raw)
In-Reply-To: <18496.1712.236440.420038@stoffel.org>
On Fri, 30 May 2008 09:52:48 -0400
"John Stoffel" <john@stoffel.org> wrote:
> I haven't seen any performance numbers talking about how well this
> stuff works on single or dual CPU machines with smaller amounts of
> memory, or whether it's worth using on these machines at all?
>
> The big machines with lots of memory and lots of CPUs are certainly
> becoming more prevalent, but for my home machine with 4Gb RAM and dual
> core, what's the advantage?
>
> Let's not slow down the common case for the sake of the bigger guys if
> possible.
I wouldn't call your home system with 4GB RAM "small".
After all, the VM that Linux currently has was developed
mostly on machines with less than 1GB of RAM and later
encrusted in bandaids to make sure the large systems did
not fail too badly.
As for small system performance, I believe that my patch
series should cause no performance regressions on those
systems and has a framework that allows us to improve
performance on those systems too.
If you manage to break performance with my patch set
somehow, please let me know so I can fix it. Something
like the VM is very subtle and any change is pretty
much guaranteed to break something, so I am very interested
in feedback.
--
All rights reversed.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-30 14:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-29 19:50 [PATCH 00/25] Vm Pageout Scalability Improvements (V8) - continued Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 13/25] Noreclaim LRU Infrastructure Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 14/25] Noreclaim LRU Page Statistics Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 15/25] Ramfs and Ram Disk pages are non-reclaimable Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 16/25] SHM_LOCKED " Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 17/25] Mlocked Pages " Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 18/25] Downgrade mmap sem while populating mlocked regions Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 19/25] Handle mlocked pages during map, remap, unmap Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 20/25] Mlocked Pages statistics Lee Schermerhorn, Nick Piggin
2008-05-29 19:51 ` [PATCH 21/25] Cull non-reclaimable pages in fault path Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 22/25] Noreclaim and Mlocked pages vm events Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 23/25] Noreclaim LRU scan sysctl Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 24/25] Mlocked Pages: count attempts to free mlocked page Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 25/25] Noreclaim LRU and Mlocked Pages Documentation Lee Schermerhorn
2008-05-29 20:16 ` [PATCH 00/25] Vm Pageout Scalability Improvements (V8) - continued Andrew Morton
2008-05-29 20:20 ` Rik van Riel
2008-05-30 1:56 ` MinChan Kim
2008-05-30 13:52 ` John Stoffel
2008-05-30 14:29 ` Rik van Riel [this message]
2008-05-30 14:36 ` John Stoffel
2008-05-30 15:27 ` Rik van Riel
2008-05-30 9:27 ` KOSAKI Motohiro
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=20080530102917.45cbca64@bree.surriel.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=eric.whitney@hp.com \
--cc=john@stoffel.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).