From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel Lespinasse Subject: Re: [PATCH -mm v9 0/8] idle memory tracking Date: Wed, 29 Jul 2015 07:12:13 -0700 Message-ID: References: <20150729123629.GI15801@dhcp22.suse.cz> <20150729135907.GT8100@esperanza> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113a36f06560a9051c042cc2 Return-path: In-Reply-To: <20150729135907.GT8100@esperanza> Sender: owner-linux-mm@kvack.org To: Vladimir Davydov Cc: Michal Hocko , Andrew Morton , Andres Lagar-Cavilla , Minchan Kim , Raghavendra K T , Johannes Weiner , Greg Thelen , David Rientjes , Pavel Emelyanov , Cyrill Gorcunov , Jonathan Corbet , linux-api@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-api@vger.kernel.org --001a113a36f06560a9051c042cc2 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov wrote: >> I guess the primary reason to rely on the pfn rather than the LRU walk, >> which would be more targeted (especially for memcg cases), is that we >> cannot hold lru lock for the whole LRU walk and we cannot continue >> walking after the lock is dropped. Maybe we can try to address that >> instead? I do not think this is easy to achieve but have you considered >> that as an option? > > Yes, I have, and I've come to a conclusion it's not doable, because LRU > lists can be constantly rotating at an arbitrary rate. If you have an > idea in mind how this could be done, please share. > > Speaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages: > - You can distribute a walk in time to avoid CPU bursts. > - You are free to parallelize the scanner as you wish to decrease the > scan time. There is a third way: one could go through every MM in the system and scan their page tables. Doing things that way turns out to be generally faster than scanning by physical address, because you don't have to go through RMAP for every page. But, you end up needing to take the mmap_sem lock of every MM (in turn) while scanning them, and that degrades quickly under memory load, which is exactly when you most need this feature. So, scan by address is still what we use here. My only concern about the interface is that it exposes the fact that the scan is done by address - if the interface only showed per-memcg totals, it would make it possible to change the implementation underneath if we somehow figure out how to work around the mmap_sem issue in the future. I don't think that is necessarily a blocker but this is something to keep in mind IMO. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. --001a113a36f06560a9051c042cc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2015 at 6:59 AM, Vladimir Davydov <vdavydov@parallels.com> wrote:
>> I gu= ess the primary reason to rely on the pfn rather than the LRU walk,
>= > which would be more targeted (especially for memcg cases), is that we<= br>>> cannot hold lru lock for the whole LRU walk and we cannot conti= nue
>> walking after the lock is dropped. Maybe we can try to addr= ess that
>> instead? I do not think this is easy to achieve but ha= ve you considered
>> that as an option?
>
> Yes, I hav= e, and I've come to a conclusion it's not doable, because LRU
&g= t; lists can be constantly rotating at an arbitrary rate. If you have an> idea in mind how this could be done, please share.
>
> Sp= eaking of LRU-vs-PFN walk, iterating over PFNs has its own advantages:
&= gt; =C2=A0- You can distribute a walk in time to avoid CPU bursts.
> = =C2=A0- You are free to parallelize the scanner as you wish to decrease the=
> =C2=A0 =C2=A0scan time.

There is a third way: one could go = through every MM in the system and scan their page tables. Doing things tha= t way turns out to be generally faster than scanning by physical address, b= ecause you don't have to go through RMAP for every page. But, you end u= p needing to take the mmap_sem lock of every MM (in turn) while scanning th= em, and that degrades quickly under memory load, which is exactly when you = most need this feature. So, scan by address is still what we use here.
<= br>My only concern about the interface is that it exposes the fact that the= scan is done by address - if the interface only showed per-memcg totals, i= t would make it possible to change the implementation underneath if we some= how figure out how to work around the mmap_sem issue in the future. I don&#= 39;t think that is necessarily a blocker but this is something to keep in m= ind IMO.

--
Michel "Walken" Lespinasse
A program is= never fully debugged until the last user dies.
--001a113a36f06560a9051c042cc2-- -- 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/ . Don't email: email@kvack.org