search for: movability

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

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

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

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

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

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

This patch describes what a subsystem should do for non-lru movable page supporting. Cc: Jonathan Corbet <corbet at lwn.net> Signed-off-by: Minchan Kim <minchan at kernel.org> --- Documentation/filesystems/vfs.txt | 11 ++++++- Documentation/vm/page_migration | 69 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 78 insertions(+), 2 deletions(-) diff --git

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

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

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/09/16 11:20), Minchan Kim wrote: [..] > +++ b/include/linux/migrate.h > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES]; > > #ifdef CONFIG_MIGRATION > > +extern int PageMovable(struct page *page); > +extern void __SetPageMovable(struct page *page, struct address_space *mapping); > +extern void __ClearPageMovable(struct page *page); > extern

On (05/09/16 11:20), Minchan Kim wrote: [..] > +++ b/include/linux/migrate.h > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES]; > > #ifdef CONFIG_MIGRATION > > +extern int PageMovable(struct page *page); > +extern void __SetPageMovable(struct page *page, struct address_space *mapping); > +extern void __ClearPageMovable(struct page *page); > extern

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

On Mon, Mar 21, 2016 at 03:31:02PM +0900, 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

On Mon, Mar 21, 2016 at 03:31:02PM +0900, 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

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