Displaying 14 results from an estimated 14 matches for "zspage_order".
Did you mean:
page_order
2016 Mar 15
1
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...> +++ b/mm/zsmalloc.c
> @@ -32,8 +32,6 @@
> * page->freelist: points to the first free object in zspage.
> * Free objects are linked together using in-place
> * metadata.
> - * page->objects: maximum number of objects we can store in this
> - * zspage (class->zspage_order * PAGE_SIZE / class->size)
> * page->lru: links together first pages of various zspages.
> * Basically forming list of zspages in a fullness group.
> * page->mapping: class index and fullness group of the zspage
> @@ -211,6 +209,7 @@ struct size_class {
> * of ZS_A...
2016 Mar 15
1
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...> +++ b/mm/zsmalloc.c
> @@ -32,8 +32,6 @@
> * page->freelist: points to the first free object in zspage.
> * Free objects are linked together using in-place
> * metadata.
> - * page->objects: maximum number of objects we can store in this
> - * zspage (class->zspage_order * PAGE_SIZE / class->size)
> * page->lru: links together first pages of various zspages.
> * Basically forming list of zspages in a fullness group.
> * page->mapping: class index and fullness group of the zspage
> @@ -211,6 +209,7 @@ struct size_class {
> * of ZS_A...
2016 Mar 12
1
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...t; +++ b/mm/zsmalloc.c
> @@ -32,8 +32,6 @@
> * page->freelist: points to the first free object in zspage.
> * Free objects are linked together using in-place
> * metadata.
> - * page->objects: maximum number of objects we can store in this
> - * zspage (class->zspage_order * PAGE_SIZE / class->size)
> * page->lru: links together first pages of various zspages.
> * Basically forming list of zspages in a fullness group.
> * page->mapping: class index and fullness group of the zspage
> @@ -211,6 +209,7 @@ struct size_class {
> * of...
2016 Mar 12
1
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...t; +++ b/mm/zsmalloc.c
> @@ -32,8 +32,6 @@
> * page->freelist: points to the first free object in zspage.
> * Free objects are linked together using in-place
> * metadata.
> - * page->objects: maximum number of objects we can store in this
> - * zspage (class->zspage_order * PAGE_SIZE / class->size)
> * page->lru: links together first pages of various zspages.
> * Basically forming list of zspages in a fullness group.
> * page->mapping: class index and fullness group of the zspage
> @@ -211,6 +209,7 @@ struct size_class {
> * of...
2016 Mar 15
0
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...> @@ -32,8 +32,6 @@
> > * page->freelist: points to the first free object in zspage.
> > * Free objects are linked together using in-place
> > * metadata.
> > - * page->objects: maximum number of objects we can store in this
> > - * zspage (class->zspage_order * PAGE_SIZE / class->size)
> > * page->lru: links together first pages of various zspages.
> > * Basically forming list of zspages in a fullness group.
> > * page->mapping: class index and fullness group of the zspage
> > @@ -211,6 +209,7 @@ struct size_class...
2016 Mar 11
0
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...3c82c1fc 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -32,8 +32,6 @@
* page->freelist: points to the first free object in zspage.
* Free objects are linked together using in-place
* metadata.
- * page->objects: maximum number of objects we can store in this
- * zspage (class->zspage_order * PAGE_SIZE / class->size)
* page->lru: links together first pages of various zspages.
* Basically forming list of zspages in a fullness group.
* page->mapping: class index and fullness group of the zspage
@@ -211,6 +209,7 @@ struct size_class {
* of ZS_ALIGN.
*/
int size;
+...
2016 Mar 30
0
[PATCH v3 05/16] zsmalloc: keep max_object in size_class
...d0243e6c 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -32,8 +32,6 @@
* page->freelist: points to the first free object in zspage.
* Free objects are linked together using in-place
* metadata.
- * page->objects: maximum number of objects we can store in this
- * zspage (class->zspage_order * PAGE_SIZE / class->size)
* page->lru: links together first pages of various zspages.
* Basically forming list of zspages in a fullness group.
* page->mapping: class index and fullness group of the zspage
@@ -211,6 +209,7 @@ struct size_class {
* of ZS_ALIGN.
*/
int size;
+...
2016 Mar 14
0
[PATCH v1 09/19] zsmalloc: keep max_object in size_class
...gt; >@@ -32,8 +32,6 @@
> > * page->freelist: points to the first free object in zspage.
> > * Free objects are linked together using in-place
> > * metadata.
> >- * page->objects: maximum number of objects we can store in this
> >- * zspage (class->zspage_order * PAGE_SIZE / class->size)
> > * page->lru: links together first pages of various zspages.
> > * Basically forming list of zspages in a fullness group.
> > * page->mapping: class index and fullness group of the zspage
> >@@ -211,6 +209,7 @@ struct size_class...
2016 Mar 11
31
[PATCH v1 00/19] 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 11
31
[PATCH v1 00/19] 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 21
22
[PATCH v2 00/18] 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 21
22
[PATCH v2 00/18] 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.
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.