search for: page_locked

...we use it only as a heuristic. But I guess it would require at least RCU-level protection of the page->mapping->a_op->isolate_page chain. > For avoiding that, we need another function to peek which just checks > PG_movable bit instead of all things. > > > /* > * If @page_locked is false, we cannot guarantee page->mapping's stability > * so just the function checks with PG_movable which could be false positive > * so caller should check it again under PG_lock to check a_ops->isolate_page. > */ > static inline int PageMovable(struct page *page, b...

...we use it only as a heuristic. But I guess it would require at least RCU-level protection of the page->mapping->a_op->isolate_page chain. > For avoiding that, we need another function to peek which just checks > PG_movable bit instead of all things. > > > /* > * If @page_locked is false, we cannot guarantee page->mapping's stability > * so just the function checks with PG_movable which could be false positive > * so caller should check it again under PG_lock to check a_ops->isolate_page. > */ > static inline int PageMovable(struct page *page, b...

On 04/04/2016 04:25 AM, Minchan Kim wrote: >> >> Ah, I see, so it's designed with page lock to handle the concurrent isolations etc. >> >> In http://marc.info/?l=linux-mm&m=143816716511904&w=2 Mel has warned >> about doing this in general under page_lock and suggested that each >> user handles concurrent calls to isolate_page() internally. Might be

On 04/04/2016 04:25 AM, Minchan Kim wrote: >> >> Ah, I see, so it's designed with page lock to handle the concurrent isolations etc. >> >> In http://marc.info/?l=linux-mm&m=143816716511904&w=2 Mel has warned >> about doing this in general under page_lock and suggested that each >> user handles concurrent calls to isolate_page() internally. Might be

Per Vlastimil's review comment, Vlastimil, I updated based on your comment. Please review this. If everything is done, I will send v7 rebased on recent mmotm. Thanks for the review! >From ad4157e98651a2d18fd0a4ae90d1d9f609aab314 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan at kernel.org> Date: Fri, 8 Apr 2016 10:34:49 +0900 Subject: [PATCH v6r2] mm: migrate: support non-lru

Per Vlastimil's review comment, Vlastimil, I updated based on your comment. Please review this. If everything is done, I will send v7 rebased on recent mmotm. Thanks for the review! >From ad4157e98651a2d18fd0a4ae90d1d9f609aab314 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan at kernel.org> Date: Fri, 8 Apr 2016 10:34:49 +0900 Subject: [PATCH v6r2] mm: migrate: support non-lru

On Mon, May 30, 2016 at 11:36:07AM +0200, Vlastimil Babka wrote: > On 05/30/2016 03:39 AM, Minchan Kim wrote: > >After isolation, VM calls migratepage of driver with isolated page. > >The function of migratepage is to move content of the old page to new page > >and set up fields of struct page newpage. Keep in mind that you should > >clear PG_movable of oldpage via

On Mon, May 30, 2016 at 11:36:07AM +0200, Vlastimil Babka wrote: > On 05/30/2016 03:39 AM, Minchan Kim wrote: > >After isolation, VM calls migratepage of driver with isolated page. > >The function of migratepage is to move content of the old page to new page > >and set up fields of struct page newpage. Keep in mind that you should > >clear PG_movable of oldpage via

We have allowed migration for only LRU pages until now and it was enough to make high-order pages. But recently, embedded system(e.g., webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) so we have seen several reports about troubles of small high-order allocation. For fixing the problem, there were several efforts (e,g,. enhance compaction algorithm, SLUB fallback to 0-order

plain text document attachment (lguest64.patch) This is the main core code for the lguest64. Have fun, and don't hurt the puppies! Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Glauber de Oliveira Costa <glommer@gmail.com> Cc: Chris Wright <chrisw@sous-sol.org> Index: work-pv/arch/x86_64/lguest/Makefile

plain text document attachment (lguest64.patch) This is the main core code for the lguest64. Have fun, and don't hurt the puppies! Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Glauber de Oliveira Costa <glommer@gmail.com> Cc: Chris Wright <chrisw@sous-sol.org> Index: work-pv/arch/x86_64/lguest/Makefile

We have allowed migration for only LRU pages until now and it was enough to make high-order pages. But recently, embedded system(e.g., webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) so we have seen several reports about troubles of small high-order allocation. For fixing the problem, there were several efforts (e,g,. enhance compaction algorithm, SLUB fallback to 0-order

On 05/20/2016 04:23 PM, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > so we have seen several reports about troubles of small high-order > allocation. For fixing the problem, there were several

On 05/20/2016 04:23 PM, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > so we have seen several reports about troubles of small high-order > allocation. For fixing the problem, there were several

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot

Per Vlastimi's review comment. Thanks for the detail review, Vlastimi! If you have another concern, feel free to say. After I resolve all thing, I will send v7 rebased on recent mmotm. >From b14aaeeeeb2d3ac0702c7b2eec36409d74406d43 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan at kernel.org> Date: Fri, 8 Apr 2016 10:34:49 +0900 Subject: [PATCH] mm: migrate: support non-lru

On Fri, May 27, 2016 at 04:26:21PM +0200, Vlastimil Babka wrote: > On 05/20/2016 04:23 PM, Minchan Kim wrote: > >We have allowed migration for only LRU pages until now and it was > >enough to make high-order pages. But recently, embedded system(e.g., > >webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) > >so we have seen several reports about

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 On 03/30/2016 09:12 AM, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g.,

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 On 03/30/2016 09:12 AM, Minchan Kim wrote: > We have allowed migration for only LRU pages until now and it was > enough to make high-order pages. But recently, embedded system(e.g., > webOS, android) uses lots of non-movable pages(e.g.,