Re: [Results] [RFC PATCH v4 00/40] mm: Memory Power Management
From: Arjan van de Ven <hidden>
Date: 2013-09-26 18:06:40
Also in:
linux-mm, lkml
quoted
quoted
quoted
Arjan, are you referring to the fact that Intel/SNB systems can exploit memory self-refresh only when the entire system goes idle? Is that why this patchset won't turn out to be that useful on those platforms?no we can use other things (CKE and co) all the time.Ah, ok..quoted
just that we found that statistical grouping gave 95%+ of the benefit, without the cost of being aggressive on going to a 100.00% groupingAnd how do you do that statistical grouping? Don't you need patches similar to those in this patchset? Or are you saying that the existing vanilla kernel itself does statistical grouping somehow?
so the way I scanned your patchset.. half of it is about grouping, the other half (roughly) is about moving stuff. the grouping makes total sense to me. actively moving is the part that I am very worried about; that part burns power to do (and performance).... for which the ROI is somewhat unclear to me (but... data speaks. I can easily be convinced with data that proves one way or the other) is moving stuff around the 95%-of-the-work-for-the-last-5%-of-the-theoretical-gain or is statistical grouping enough to get > 95% of the gain... without the cost of moving.
Also, I didn't fully understand how NUMA policy will help in this case.. If you want to group memory allocations/references into fewer memory regions _within_ a node, will NUMA policy really help? For example, in this patchset, everything (all the allocation/reference shaping) is done _within_ the NUMA boundary, assuming that the memory regions are subsets of a NUMA node. Regards, Srivatsa S. Bhat