On Sat, Jun 11, 2011 at 10:26:54AM -0700, Arjan van de Ven wrote: > 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) Ah, OK, so you have a very large number of top-level buddy allocations, then. Either that or very large 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). That is indeed a clever approach! Of course, if the GPU textures are in main memory, there will still be memory consumption gains to be had as the image size varies (e.g., displaying image on one hand vs. menus and UI on the other). In addition, I would expect that for quite some time there will continue to be a lot of systems with display hardware a bit too simple to qualify as "GPU". Thanx, Paul -- 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>