search for: da1b13ccfbebe

Displaying 15 results from an estimated 15 matches for "da1b13ccfbebe".

2016 Apr 05
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...: ... > >>> > >>> 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. > >> > >> Yes, while I read the code, I had same question. I think the releasing > >> refcount is for get_any_page. > > > > As the other callers of pa...
2016 Apr 05
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...: ... > >>> > >>> 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. > >> > >> Yes, while I read the code, I had same question. I think the releasing > >> refcount is for get_any_page. > > > > As the other callers of pa...
2016 Apr 04
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...catching and > kill the poor proces. > > > > > 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. > > Yes, while I read the code, I had same question. I think the releasing > refcount is for get_any_page. As the other callers of page migration do, soft_offline_page expects the migratio...
2016 Apr 04
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...catching and > kill the poor proces. > > > > > 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. > > Yes, while I read the code, I had same question. I think the releasing > refcount is for get_any_page. As the other callers of page migration do, soft_offline_page expects the migratio...
2016 Apr 05
0
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...gt;>> >>>>> 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. >>>> >>>> Yes, while I read the code, I had same question. I think the releasing >>>> refcount is for get_any_page. >>> >>> As the ot...
2016 Apr 06
1
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...;>>>> 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. > >>>> > >>>> Yes, while I read the code, I had same question. I think the releasing > >>>> refcount is for get_any_page. > >>&g...
2016 Apr 06
1
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...;>>>> 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. > >>>> > >>>> Yes, while I read the code, I had same question. I think the releasing > >>>> refcount is for get_any_page. > >>&g...
2016 Apr 01
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...ion of hwpoison, which is IIRC to catch and kill the poor process that still uses the page? 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. > + } else { > + if (rc != -EAGAIN) > putback_lru_page(page); > + if (put_new_page) > + put_new_page(newpage, private); > + else > + put_page(newpage); > } > > -...
2016 Apr 01
2
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...ion of hwpoison, which is IIRC to catch and kill the poor process that still uses the page? 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. > + } else { > + if (rc != -EAGAIN) > putback_lru_page(page); > + if (put_new_page) > + put_new_page(newpage, private); > + else > + put_page(newpage); > } > > -...
2016 Apr 04
0
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...kill the poor proces. >> >>> >>> 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. >> >> Yes, while I read the code, I had same question. I think the releasing >> refcount is for get_any_page. > > As the other callers of page migration do, soft_offline_...
2016 Apr 04
1
mm/hwpoison: fix wrong num_poisoned_pages account
...r proces. > > > > > > > > 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. > > > > Yes, while I read the code, I had same question. I think the releasing > > refcount is for get_any_page. > > As the other callers of page migration do, soft_off...
2016 Apr 04
1
mm/hwpoison: fix wrong num_poisoned_pages account
...r proces. > > > > > > > > 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. > > > > Yes, while I read the code, I had same question. I think the releasing > > refcount is for get_any_page. > > As the other callers of page migration do, soft_off...
2016 Apr 04
0
[PATCH v3 01/16] mm: use put_page to free page instead of putback_lru_page
...page so I think it's not for catching and kill the poor proces. > > 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. Yes, while I read the code, I had same question. I think the releasing refcount is for get_any_page. Naoya, could you answer above two questions? Thanks. > > >+ } else { > >+ if (rc...
2016 Mar 30
33
[PATCH v3 00/16] Support non-lru page migration
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.
2016 Mar 30
33
[PATCH v3 00/16] Support non-lru page migration
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.