From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx200.postini.com [74.125.245.200]) by kanga.kvack.org (Postfix) with SMTP id D67A76B13F0 for ; Tue, 31 Jan 2012 07:39:09 -0500 (EST) Date: Tue, 31 Jan 2012 13:39:03 +0100 From: Ingo Molnar Subject: Re: [RFCv1 0/6] PASR: Partial Array Self-Refresh Framework Message-ID: <20120131123903.GB4408@elte.hu> References: <1327930436-10263-1-git-send-email-maxime.coquelin@stericsson.com> <20120130135341.GA3720@elte.hu> <4F26A701.3090006@stericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F26A701.3090006@stericsson.com> Sender: owner-linux-mm@kvack.org List-ID: To: Maxime Coquelin Cc: "linux-mm@kvack.org" , "linaro-mm-sig@lists.linaro.org" , Mel Gorman , "linux-kernel@vger.kernel.org" , Linus WALLEIJ , Andrea GALLO , Vincent GUITTOT , Philippe LANGLAIS , Loic PALLARDY , Andrew Morton , Linus Torvalds , Thomas Gleixner , Peter Zijlstra * Maxime Coquelin wrote: > Dear Ingo, > > On 01/30/2012 02:53 PM, Ingo Molnar wrote: > >* Maxime Coquelin wrote: > > > >>The role of this framework is to stop the refresh of unused > >>memory to enhance DDR power consumption. > >I'm wondering in what scenarios this is useful, and how > >consistently it is useful. > > > >The primary concern I can see is that on most Linux systems with > >an uptime more than a couple of minutes RAM gets used up by the > >Linux page-cache: > > > > $ uptime > > 14:46:39 up 11 days, 2:04, 19 users, load average: 0.11, 0.29, 0.80 > > $ free > > total used free shared buffers cached > > Mem: 12255096 12030152 224944 0 651560 6000452 > > -/+ buffers/cache: 5378140 6876956 > > > > Even mobile phones easily have days of uptime - quite often > > weeks of uptime. I'd expect the page-cache to fill up RAM on > > such systems. > > > > So how will this actually end up saving power consistently? > > Does it have to be combined with a VM policy that more > > aggressively flushes cached pages from the page-cache? > > You're right Ingo, page-cache fills up the RAM. This framework > is to be used in combination with a page-cache flush governor. > In the case of a mobile phone, we can imagine dropping the > cache when system's screen is off for a while, in order to > preserve user's experience. Is this "page-cache flush governor" some existing code? How does it work and does it need upstream patches? > > A secondary concern is fragmentation: right now we fragment > > memory rather significantly. > > Yes, I think fragmentation is the main challenge. This is the > same problem faced for Memory Hotplug feature. The solution I > see is to add a significant Movable zone in the system and use > the Compaction feature from Mel Gorman. The problem of course > remains for the Normal zone. Ok. I guess phones/appliances can generally live with a relatively large movable zone as they don't have serious memory pressure issues. > > For the Ux500 PASR driver you've implemented the section > > size is 64 MB. Do I interpret the code correctly in that a > > continuous, 64MB physical block of RAM has to be 100% free > > for us to be able to turn off refresh and power for this > > block of RAM? > > Current DDR (2Gb/4Gb dies) used in mobile platform have 64MB > banks and segments. This is the lower granularity for Partial > Array Self-refresh. Ok, so do you see real, consistent power savings with a large movable zone, with page cache governor patches applied (assuming it's a kernel mechanism) and CONFIG_COMPACTION=y enabled, on an upstream kernel with all these patches applied? Thanks, Ingo -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org