search for: 0f6cce9b9119

We don't use page->_mapcount any more so no need to reset. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 4dd72a803568..0f6cce9b9119 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -922,7 +922,6 @@ static void reset_page(struct page *page) set_page_private(page, 0); page->mapping = NULL; page->freelist = NULL; - page_mapcount_reset(page); } static void free_zspage(struct page *first_page) -- 1.9.1

...number of bit we need to store offset is at most 11bit. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 158 +++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 96 insertions(+), 62 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 0f6cce9b9119..807998462539 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -18,9 +18,7 @@ * Usage of struct page fields: * page->private: points to the first component (0-order) page * page->index (union with page->freelist): offset of the first object - * starting in this page. For the first...

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.