Hi, On Fri, Jun 10, 2011 at 08:02:33PM -0700, Arjan van de Ven wrote: > On Fri, 10 Jun 2011 12:37:13 -0700 > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > > > On Fri, Jun 10, 2011 at 08:23:29PM +0100, Matthew Garrett wrote: > > > On Fri, Jun 10, 2011 at 11:47:38AM -0700, Paul E. McKenney wrote: > > > > > > > And if I understand you correctly, then the patches that Ankita > > > > posted should help your self-refresh case, along with the > > > > originally intended the power-down case and special-purpose use > > > > of memory case. > > > > > > Yeah, I'd hope so once we actually have capable hardware. > > > > Cool!!! > > > > So Ankita's patchset might be useful to you at some point, then. > > > > Does it look like a reasonable implementation? > > as someone who is working on hardware that is PASR capable right now, > I have to admit that our plan was to just hook into the buddy allocator, > and use PASR on the top level of buddy (eg PASR off blocks that are > free there, and PASR them back on once an allocation required the block > to be broken up)..... that looked the very most simple to me. > The maximum order in buddy allocator is by default 1k pages. Isn't this too small a granularity to track blocks that might comprise a PASR unit? > Maybe something much more elaborate is needed, but I didn't see why so > far. > > -- Regards, Ankita Garg (ankita@xxxxxxxxxx) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>