On Sat, 11 Jun 2011 10:06:10 -0700 "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > 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. > > > > Maybe something much more elaborate is needed, but I didn't see why > > so far. > > If I understand correctly, you face the same issue that affects > transparent huge pages, but on a much larger scale. If you have even > one non-moveable allocation in a given top-level buddy block, you > won't be able to PASR that block. yep we'd use a non-kernel zone for that; not too big a deal. (the much larger scale you can debate, if your memory controller is configured correctly the PASR regions are not all that much bigger than hugepages) > > In addition, one of the things that Ankita's patchset is looking to do > is to control allocations in a given region, so that the region can be > easily evacuated. One use for this is to power off regions of memory, > another is to PASR off regions of memory, and a third is to ensure > that large regions of memory are available for when needed by media > codecs (e.g., cameras), but can be used for other purposes when the > media codecs don't need them (e.g., when viewing photos rather than > taking them). the codec issue seems to be solved in time; a previous generation silicon on our (Intel) side had ARM ecosystem blocks that did not do scatter gather, however the current generation ARM ecosystem blocks all seem to have added S/G to them.... (in part this is coming from the strong desire to get camera/etc blocks to all use "GPU texture" class memory, so that the camera can directly deposit its information into a gpu texture, and similar for media encode/decode blocks... this avoids copies as well as duplicate memory). -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
