From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx201.postini.com [74.125.245.201]) by kanga.kvack.org (Postfix) with SMTP id 00D4B6B005C for ; Mon, 30 Jan 2012 09:20:47 -0500 (EST) Message-ID: <4F26A701.3090006@stericsson.com> Date: Mon, 30 Jan 2012 15:19:45 +0100 From: Maxime Coquelin MIME-Version: 1.0 Subject: Re: [RFCv1 0/6] PASR: Partial Array Self-Refresh Framework References: <1327930436-10263-1-git-send-email-maxime.coquelin@stericsson.com> <20120130135341.GA3720@elte.hu> In-Reply-To: <20120130135341.GA3720@elte.hu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar 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 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. > > 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. > 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. Thanks for your comments, Maxime > 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