search for: vlastimil

On 05/31/2016 02:01 AM, Minchan Kim wrote: > Per Vlastimi's review comment. > > Thanks for the detail review, Vlastimi! > If you have another concern, feel free to say. I don't for now :) [...] > Cc: Rik van Riel <riel at redhat.com> > Cc: Vlastimil Babka <vbabka at suse.cz> > Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com> > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Rafael Aquini <aquini at redhat.com> > Cc: virtualization at lists.linux-foundation.org > Cc:...

On 05/31/2016 02:01 AM, Minchan Kim wrote: > Per Vlastimi's review comment. > > Thanks for the detail review, Vlastimi! > If you have another concern, feel free to say. I don't for now :) [...] > Cc: Rik van Riel <riel at redhat.com> > Cc: Vlastimil Babka <vbabka at suse.cz> > Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com> > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Rafael Aquini <aquini at redhat.com> > Cc: virtualization at lists.linux-foundation.org > Cc:...

...> So, this patch cleans it up to divide two semantic(ie, put and putback). > If migration is successful, use put_page instead of putback_lru_page and > use putback_lru_page only on failure. That makes code more readable > and doesn't add overhead in put_page. > > Comment from Vlastimil > "Yeah, and compaction (perhaps also other migration users) has to drain > the lru pvec... Getting rid of this stuff is worth even by itself." > > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Naoya Horiguchi <n-horigu...

...> So, this patch cleans it up to divide two semantic(ie, put and putback). > If migration is successful, use put_page instead of putback_lru_page and > use putback_lru_page only on failure. That makes code more readable > and doesn't add overhead in put_page. > > Comment from Vlastimil > "Yeah, and compaction (perhaps also other migration users) has to drain > the lru pvec... Getting rid of this stuff is worth even by itself." > > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Naoya Horiguchi <n-horigu...

...> use putback_lru_page only on failure. That makes code more readable > and doesn't add overhead in put_page. I had an idea of checking for count==1 in putback_lru_page() which would take the put_page() shortcut from there. But maybe it can't be done nicely without races. > Cc: Vlastimil Babka <vbabka at suse.cz> > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Naoya Horiguchi <n-horiguchi at ah.jp.nec.com> > Signed-off-by: Minchan Kim <minchan at kernel.org> Acked-by: Vlastimil Babka <vbabka at suse....

...> use putback_lru_page only on failure. That makes code more readable > and doesn't add overhead in put_page. I had an idea of checking for count==1 in putback_lru_page() which would take the put_page() shortcut from there. But maybe it can't be done nicely without races. > Cc: Vlastimil Babka <vbabka at suse.cz> > Cc: Mel Gorman <mgorman at suse.de> > Cc: Hugh Dickins <hughd at google.com> > Cc: Naoya Horiguchi <n-horiguchi at ah.jp.nec.com> > Signed-off-by: Minchan Kim <minchan at kernel.org> Acked-by: Vlastimil Babka <vbabka at suse....

Forking new thread, Hello Naoya, On Mon, Apr 04, 2016 at 04:45:12AM +0000, Naoya Horiguchi wrote: > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > > >Procedure of page migration is as follows: > > > > > > > >First of all, it should isolate a page from LRU and try to > > > >migrate the page. If it is successful, it release...

Forking new thread, Hello Naoya, On Mon, Apr 04, 2016 at 04:45:12AM +0000, Naoya Horiguchi wrote: > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > > >Procedure of page migration is as follows: > > > > > > > >First of all, it should isolate a page from LRU and try to > > > >migrate the page. If it is successful, it release...

On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > On 03/30/2016 09:12 AM, Minchan Kim wrote: > >Procedure of page migration is as follows: > > > >First of all, it should isolate a page from LRU and try to > >migrate the page. If it is successful, it releases the page > >for freeing. Otherwise, it sho...

On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > >Procedure of page migration is as follows: > > > > > >First of all, it should isolate a page from LRU and try to > > >migrate the page. If it is successful, it releases the page > > >...

On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 02:58:21PM +0200, Vlastimil Babka wrote: > > On 03/30/2016 09:12 AM, Minchan Kim wrote: > > >Procedure of page migration is as follows: > > > > > >First of all, it should isolate a page from LRU and try to > > >migrate the page. If it is successful, it releases the page > > >...

On Mon, Mar 14, 2016 at 09:48:33AM +0100, Vlastimil Babka wrote: > On 03/11/2016 08:30 AM, Minchan Kim wrote: > >Procedure of page migration is as follows: > > > >First of all, it should isolate a page from LRU and try to > >migrate the page. If it is successful, it releases the page > >for freeing. Otherwise, it sho...

On 04/04/2016 07:12 AM, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: >> Might have been better as a separate migration patch and then a >> compaction patch. It's prefixed mm/compaction, but most changed are >> in mm/migrate.c > > Indeed. The title is rather misleading but not sure it's a good idea > to separate compact...

On 04/04/2016 07:12 AM, Minchan Kim wrote: > On Fri, Apr 01, 2016 at 11:29:14PM +0200, Vlastimil Babka wrote: >> Might have been better as a separate migration patch and then a >> compaction patch. It's prefixed mm/compaction, but most changed are >> in mm/migrate.c > > Indeed. The title is rather misleading but not sure it's a good idea > to separate compact...

...> vmalloc for sizes above PAGE_SIZE? Even if that was the case then this doesn't sounds like CONFIG_DEBUG_VM material. We do not want a completely different behavior when the config is enabled. If we really need some better fallback testing coverage then the fault injection, as suggested by Vlastimil, sounds much more reasonable to me -- Michal Hocko SUSE Labs

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment...

On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: ... > >>> > >>> Also (but not your fault) the put_page() preceding > >>> test_set_page_hwpoison(page)) IMHO deserves a comment...

...he flag check with put_page. So, this patch cleans it up to divide two semantic(ie, put and putback). If migration is successful, use put_page instead of putback_lru_page and use putback_lru_page only on failure. That makes code more readable and doesn't add overhead in put_page. Comment from Vlastimil "Yeah, and compaction (perhaps also other migration users) has to drain the lru pvec... Getting rid of this stuff is worth even by itself." Cc: Mel Gorman <mgorman at suse.de> Cc: Hugh Dickins <hughd at google.com> Cc: Naoya Horiguchi <n-horiguchi at ah.jp.nec.com> Acke...

On Tue, Apr 05, 2016 at 10:20:50AM +0200, Vlastimil Babka wrote: > On 04/05/2016 03:54 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > >> On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > >>> On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > ... >...

On Tue, Apr 05, 2016 at 10:20:50AM +0200, Vlastimil Babka wrote: > On 04/05/2016 03:54 AM, Naoya Horiguchi wrote: > > On Mon, Apr 04, 2016 at 04:46:31PM +0200, Vlastimil Babka wrote: > >> On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > >>> On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: > > ... >...