similar to: mm/hwpoison: fix wrong num_poisoned_pages account

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 should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

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 should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

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

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

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 saying which > >>> pin we are

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 saying which > >>> pin we are

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: > > ... > >>>>> > >>>>>

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 should put the page back to LRU > >list. >

On 04/04/2016 06:45 AM, Naoya Horiguchi wrote: > On Mon, Apr 04, 2016 at 10:39:17AM +0900, Minchan Kim wrote: >> Thanks for catching it, Vlastimil. >> It was my mistake. But in this chance, I looked over hwpoison code and >> I saw other places which increases num_poisoned_pages are successful >> migration, already freed page and successful invalidated page. >> IOW,

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: > ... >>>>> >>>>> Also (but not your fault) the put_page() preceding >>>>> test_set_page_hwpoison(page))

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 should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

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 should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

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 should put the page back to LRU list. For LRU pages, we have used putback_lru_page for both freeing and putback to LRU list. It's okay because put_page is aware of LRU list so if it releases last refcount

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 should put the page back to LRU list. For LRU pages, we have used putback_lru_page for both freeing and putback to LRU list. It's okay because put_page is aware of LRU list so if it releases last refcount

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.

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 should put the page back to LRU > >list. >

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.