From: Petr Tesarik <ptesarik@xxxxxxx> Subject: Re: [PATCH v2 2/3] Generic handling of multi-page exclusions Date: Tue, 8 Apr 2014 12:07:28 +0200 > On Tue, 08 Apr 2014 17:19:03 +0900 (JST) > HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > >> From: Petr Tesarik <ptesarik at suse.cz> >> Subject: Re: [PATCH v2 2/3] Generic handling of multi-page exclusions >> Date: Tue, 8 Apr 2014 08:54:36 +0200 >> >> > On Tue, 08 Apr 2014 10:49:07 +0900 (JST) >> > HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: >> >> >> >> Also, it seems to me better to introduce a new type for this >> >> processing rather than extending existing code. struct mem_map_data is >> >> not specific for the excluding processing. >> > >> > Kind of agreed. OTOH it will most likely be embedded in struct >> > mem_map_data anyway, because exactly one such object per mm is needed. >> > >> > Petr T >> >> I don't understand well. It seems to me a single object is enough. Is >> it possible to nr_pages cover multiple mm's? > > In fact, I believe it may be sufficient, but the loop nesting is like > this (pseudo-code): > > for each cycle: > for each mm: > call __exclude_unnecessary_pages > > I'm not 100% sure that the region cannot change back and forth between > two consecutive calls to __exclude_unnecessary_pages. > > Thinking about it some more, this can be harmful only if there are > overlapping memory maps... Can it happen, or can I safely ignore this > possibility? > > Petr T The list of mm is sorted and not overlapping. See get_mm_sparsemem(), get_mm_sparsemem(), get_mm_discontigmem() and get_mm_flatmem() from get_mem_map(). In particular, in get_mm_discontigmem(), sorting and removing overlapping portions are done explicitly. Thanks. HATAYAMA, Daisuke
