similar to: [PATCH 0/4] enable migration of driver pages

From: Gioh Kim <gurugio at hanmail.net> Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for

From: Gioh Kim <gurugio at hanmail.net> Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for

On 07/13/2015 10:35 AM, Gioh Kim wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. Note that unlike what subject suggest,

On 07/13/2015 10:35 AM, Gioh Kim wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. Note that unlike what subject suggest,

Hi Gioh, On Mon, Jul 13, 2015 at 05:35:17PM +0900, Gioh Kim wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. > >

Hi Gioh, On Mon, Jul 13, 2015 at 05:35:17PM +0900, Gioh Kim wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. > >

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

On Tue, Jul 7, 2015 at 7:36 AM, Gioh Kim <gioh.kim at lge.com> wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. >

On Tue, Jul 7, 2015 at 7:36 AM, Gioh Kim <gioh.kim at lge.com> wrote: > From: Gioh Kim <gurugio at hanmail.net> > > Add framework to register callback functions and check page mobility. > There are some modes for page isolation so that isolate interface > has arguments of page address and isolation mode while putback > interface has only page address as argument. >

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

On Fri, Jun 26, 2015 at 12:58 PM, Gioh Kim <gioh.kim at lge.com> wrote: > Compaction calls interfaces of driver page migration > instead of calling balloon migration directly. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 1 + > mm/compaction.c | 9 +++++---- > mm/migrate.c | 21

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim <gioh.kim at lge.com> wrote: > Apply driver page migration into balloon driver. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 2 ++ > fs/proc/page.c | 4 +-- > include/linux/balloon_compaction.h | 42 ++++++++++++++++------- >

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim <gioh.kim at lge.com> wrote: > Apply driver page migration into balloon driver. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 2 ++ > fs/proc/page.c | 4 +-- > include/linux/balloon_compaction.h | 42 ++++++++++++++++------- >

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.