[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070517112357.7adc4763.akpm@linux-foundation.org>
Date: Thu, 17 May 2007 11:23:57 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: balbir@...ux.vnet.ibm.com
Cc: Pavel Emelianov <xemul@...ru>, Paul Menage <menage@...gle.com>,
Kirill Korotaev <dev@...ru>, devel@...nvz.org,
Linux Containers <containers@...ts.osdl.org>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Herbert Poetzl <herbert@...hfloor.at>
Subject: Re: RSS controller v2 Test results (lmbench )
On Thu, 17 May 2007 23:20:12 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> A meaningful container size does not hamper performance. I am in the process
> of getting more results (with varying container sizes). Please let me know
> what you think of the results? Would you like to see different benchmarks/
> tests/configuration results?
>
> Any feedback, suggestions to move this work forward towards identifying
> and correcting bottlenecks or to help improve it is highly appreciated.
<wakes up>
Memory reclaim tends not to consume much CPU. Because in steady state it
tends to be the case that the memory reclaim rate (and hopefully the
scanning rate) is equal to the disk IO rate.
Often the most successful way to identify performance problems in there is
by careful code inspection followed by development of exploits.
Is this RSS controller built on Paul's stuff, or is it standalone?
Where do we stand on all of this now anyway? I was thinking of getting Paul's
changes into -mm soon, see what sort of calamities that brings about.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists