search for: test_set_page_hwpoison

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 releasing and which one we still have (hopefully? if I > >>> read description of da1b13ccfbebe right) otherwise it looks like > >>> doing something with a page that we just potentially freed. > >&...

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 releasing and which one we still have (hopefully? if I > >>> read description of da1b13ccfbebe right) otherwise it looks like > >>> doing something with a page that we just potentially freed. > >&...

...n. Otherwise, restore the page to LRU list unless we > > >+ * want to retry. > > >+ */ > > >+ if (rc == MIGRATEPAGE_SUCCESS) { > > >+ put_page(page); > > > if (reason == MR_MEMORY_FAILURE) { > > >- put_page(page); > > > if (!test_set_page_hwpoison(page)) > > > num_poisoned_pages_inc(); > > >- } else > > >+ } > > > > Hmm, I didn't notice it previously, or it's due to rebasing, but it > > seems that you restricted the memory failure handling (i.e. setting > > hwpoison) to MIGRA...

...n. Otherwise, restore the page to LRU list unless we > > >+ * want to retry. > > >+ */ > > >+ if (rc == MIGRATEPAGE_SUCCESS) { > > >+ put_page(page); > > > if (reason == MR_MEMORY_FAILURE) { > > >- put_page(page); > > > if (!test_set_page_hwpoison(page)) > > > num_poisoned_pages_inc(); > > >- } else > > >+ } > > > > Hmm, I didn't notice it previously, or it's due to rebasing, but it > > seems that you restricted the memory failure handling (i.e. setting > > hwpoison) to MIGRA...

...mil 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 releasing and which one we still have (hopefully? if I > >>>>> read description of da1b13ccfbebe right) otherwise it looks like > >>>>> doing something with a page that we just poten...

...mil 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 releasing and which one we still have (hopefully? if I > >>>>> read description of da1b13ccfbebe right) otherwise it looks like > >>>>> doing something with a page that we just poten...

...lready freed page and successful invalidated page. >> IOW, they are already successful isolated page so I guess it should >> increase the count when only successful migration is done? > > Yes, that's right. When exiting with migration's failure, we shouldn't call > test_set_page_hwpoison or num_poisoned_pages_inc, so current code checking > (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory > error handling. Great! Ah, I see, soft onlining works differently than I thought. >> And when I read memory_failure, it bails out without killing if it >...

...RU list unless we > > > >+ * want to retry. > > > >+ */ > > > >+ if (rc == MIGRATEPAGE_SUCCESS) { > > > >+ put_page(page); > > > > if (reason == MR_MEMORY_FAILURE) { > > > >- put_page(page); > > > > if (!test_set_page_hwpoison(page)) > > > > num_poisoned_pages_inc(); > > > >- } else > > > >+ } > > > > > > Hmm, I didn't notice it previously, or it's due to rebasing, but it > > > seems that you restricted the memory failure handling (i.e. settin...

...RU list unless we > > > >+ * want to retry. > > > >+ */ > > > >+ if (rc == MIGRATEPAGE_SUCCESS) { > > > >+ put_page(page); > > > > if (reason == MR_MEMORY_FAILURE) { > > > >- put_page(page); > > > > if (!test_set_page_hwpoison(page)) > > > > num_poisoned_pages_inc(); > > > >- } else > > > >+ } > > > > > > Hmm, I didn't notice it previously, or it's due to rebasing, but it > > > seems that you restricted the memory failure handling (i.e. settin...

...16 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 releasing and which one we still have (hopefully? if I >>>>> read description of da1b13ccfbebe right) otherwise it looks like >>>>> doing something with a page that we just potentially freed. &...

...uccessful, drop the reference grabbed during > + * isolation. Otherwise, restore the page to LRU list unless we > + * want to retry. > + */ > + if (rc == MIGRATEPAGE_SUCCESS) { > + put_page(page); > if (reason == MR_MEMORY_FAILURE) { > - put_page(page); > if (!test_set_page_hwpoison(page)) > num_poisoned_pages_inc(); > - } else > + } Hmm, I didn't notice it previously, or it's due to rebasing, but it seems that you restricted the memory failure handling (i.e. setting hwpoison) to MIGRATE_SUCCESS, while previously it was done for all non-EAGAIN resul...

...uccessful, drop the reference grabbed during > + * isolation. Otherwise, restore the page to LRU list unless we > + * want to retry. > + */ > + if (rc == MIGRATEPAGE_SUCCESS) { > + put_page(page); > if (reason == MR_MEMORY_FAILURE) { > - put_page(page); > if (!test_set_page_hwpoison(page)) > num_poisoned_pages_inc(); > - } else > + } Hmm, I didn't notice it previously, or it's due to rebasing, but it seems that you restricted the memory failure handling (i.e. setting hwpoison) to MIGRATE_SUCCESS, while previously it was done for all non-EAGAIN resul...

...abbed during > >+ * isolation. Otherwise, restore the page to LRU list unless we > >+ * want to retry. > >+ */ > >+ if (rc == MIGRATEPAGE_SUCCESS) { > >+ put_page(page); > > if (reason == MR_MEMORY_FAILURE) { > >- put_page(page); > > if (!test_set_page_hwpoison(page)) > > num_poisoned_pages_inc(); > >- } else > >+ } > > Hmm, I didn't notice it previously, or it's due to rebasing, but it > seems that you restricted the memory failure handling (i.e. setting > hwpoison) to MIGRATE_SUCCESS, while previously it was...

...list */ + } + + /* + * If migration is successful, drop the reference grabbed during + * isolation. Otherwise, restore the page to LRU list unless we + * want to retry. + */ + if (rc == MIGRATEPAGE_SUCCESS) { + put_page(page); if (reason == MR_MEMORY_FAILURE) { - put_page(page); if (!test_set_page_hwpoison(page)) num_poisoned_pages_inc(); - } else + } + } else { + if (rc != -EAGAIN) putback_lru_page(page); + if (put_new_page) + put_new_page(newpage, private); + else + put_page(newpage); } - /* - * If migration was not successful and there's a freeing callback, use - * it....

...list */ + } + + /* + * If migration is successful, drop the reference grabbed during + * isolation. Otherwise, restore the page to LRU list unless we + * want to retry. + */ + if (rc == MIGRATEPAGE_SUCCESS) { + put_page(page); if (reason == MR_MEMORY_FAILURE) { - put_page(page); if (!test_set_page_hwpoison(page)) num_poisoned_pages_inc(); - } else + } + } else { + if (rc != -EAGAIN) putback_lru_page(page); + if (put_new_page) + put_new_page(newpage, private); + else + put_page(newpage); } - /* - * If migration was not successful and there's a freeing callback, use - * it....

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.

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.

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.