All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Stoffel" <john@stoffel.org>
To: Rik van Riel <riel@redhat.com>
Cc: "John Stoffel" <john@stoffel.org>,
	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:36:05 -0400	[thread overview]
Message-ID: <18496.4309.393775.511382@stoffel.org> (raw)
In-Reply-To: <20080530102917.45cbca64@bree.surriel.com>



Rik> On Fri, 30 May 2008 09:52:48 -0400
Rik> "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.

Rik> I wouldn't call your home system with 4GB RAM "small".

*grin* me either in some ways.  But my other main linux box, which
acts as an NFS server has 2Gb of RAM, but a pair of PIII Xeons at
550mhz.  This is the box I'd be worried about in some ways, since it
handles a bunch of stuff like backups, mysql, apache, NFS server,
etc.  

Rik> After all, the VM that Linux currently has was developed mostly
Rik> on machines with less than 1GB of RAM and later encrusted in
Rik> bandaids to make sure the large systems did not fail too badly.

Sure, I understand.  

Rik> As for small system performance, I believe that my patch series
Rik> should cause no performance regressions on those systems and has
Rik> a framework that allows us to improve performance on those
Rik> systems too.

Great!  It would be nice to just be able to track this nicely.

Rik> If you manage to break performance with my patch set somehow,
Rik> please let me know so I can fix it.  Something like the VM is
Rik> very subtle and any change is pretty much guaranteed to break
Rik> something, so I am very interested in feedback.

What are you using to test/benchmark your changes as you develop this
patchset?  What would you suggest as a test load to help check
performance?

John

WARNING: multiple messages have this Message-ID (diff)
From: "John Stoffel" <john@stoffel.org>
To: Rik van Riel <riel@redhat.com>
Cc: John Stoffel <john@stoffel.org>,
	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:36:05 -0400	[thread overview]
Message-ID: <18496.4309.393775.511382@stoffel.org> (raw)
In-Reply-To: <20080530102917.45cbca64@bree.surriel.com>


Rik> On Fri, 30 May 2008 09:52:48 -0400
Rik> "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.

Rik> I wouldn't call your home system with 4GB RAM "small".

*grin* me either in some ways.  But my other main linux box, which
acts as an NFS server has 2Gb of RAM, but a pair of PIII Xeons at
550mhz.  This is the box I'd be worried about in some ways, since it
handles a bunch of stuff like backups, mysql, apache, NFS server,
etc.  

Rik> After all, the VM that Linux currently has was developed mostly
Rik> on machines with less than 1GB of RAM and later encrusted in
Rik> bandaids to make sure the large systems did not fail too badly.

Sure, I understand.  

Rik> As for small system performance, I believe that my patch series
Rik> should cause no performance regressions on those systems and has
Rik> a framework that allows us to improve performance on those
Rik> systems too.

Great!  It would be nice to just be able to track this nicely.

Rik> If you manage to break performance with my patch set somehow,
Rik> please let me know so I can fix it.  Something like the VM is
Rik> very subtle and any change is pretty much guaranteed to break
Rik> something, so I am very interested in feedback.

What are you using to test/benchmark your changes as you develop this
patchset?  What would you suggest as a test load to help check
performance?

John

--
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>

  reply	other threads:[~2008-05-30 14:36 UTC|newest]

Thread overview: 44+ 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 ` Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 13/25] Noreclaim LRU Infrastructure Lee Schermerhorn
2008-05-29 19:50   ` Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 14/25] Noreclaim LRU Page Statistics Lee Schermerhorn
2008-05-29 19:50   ` 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   ` Lee Schermerhorn
2008-05-29 19:50 ` [PATCH 16/25] SHM_LOCKED " Lee Schermerhorn
2008-05-29 19:50   ` Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 17/25] Mlocked Pages " Lee Schermerhorn
2008-05-29 19:51   ` Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 18/25] Downgrade mmap sem while populating mlocked regions Lee Schermerhorn
2008-05-29 19:51   ` 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   ` Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 20/25] Mlocked Pages statistics Lee Schermerhorn
2008-05-29 19:51   ` Lee Schermerhorn, Nick Piggin
2008-05-29 19:51 ` [PATCH 21/25] Cull non-reclaimable pages in fault path Lee Schermerhorn
2008-05-29 19:51   ` Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 22/25] Noreclaim and Mlocked pages vm events Lee Schermerhorn
2008-05-29 19:51   ` Lee Schermerhorn, Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 23/25] Noreclaim LRU scan sysctl Lee Schermerhorn
2008-05-29 19:51   ` 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   ` Lee Schermerhorn
2008-05-29 19:51 ` [PATCH 25/25] Noreclaim LRU and Mlocked Pages Documentation Lee Schermerhorn
2008-05-29 19:51   ` Lee Schermerhorn
2008-05-29 20:16 ` [PATCH 00/25] Vm Pageout Scalability Improvements (V8) - continued Andrew Morton
2008-05-29 20:16   ` Andrew Morton
2008-05-29 20:20   ` Rik van Riel
2008-05-29 20:20     ` Rik van Riel
2008-05-30  1:56     ` MinChan Kim
2008-05-30  1:56       ` MinChan Kim
2008-05-30 13:52     ` John Stoffel
2008-05-30 13:52       ` John Stoffel
2008-05-30 14:29       ` Rik van Riel
2008-05-30 14:29         ` Rik van Riel
2008-05-30 14:36         ` John Stoffel [this message]
2008-05-30 14:36           ` John Stoffel
2008-05-30 15:27           ` Rik van Riel
2008-05-30 15:27             ` Rik van Riel
2008-05-30  9:27 ` KOSAKI Motohiro
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=18496.4309.393775.511382@stoffel.org \
    --to=john@stoffel.org \
    --cc=akpm@linux-foundation.org \
    --cc=eric.whitney@hp.com \
    --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 \
    --cc=riel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.