search for: 11bit

Currently, we store class:fullness into page->mapping. The number of class we can support is 255 and fullness is 4 so (8 + 2 = 10bit) is enough to represent them. Meanwhile, the bits we need to store in-use objects in zspage is that 11bit is enough. For example, If we assume that 64K PAGE_SIZE, class_size 32 which is worst case, class->pages_per_zspage become 1 so the number of objects in zspage is 2048 so 11bit is enough. The next class is 32 + 256(i.e., ZS_SIZE_CLASS_DELTA). With worst case that ZS_MAX_PAGES_PER_ZSPAGE, 64K *...

Zsmalloc stores first free object's position into first_page->freelist in each zspage. If we change it with object index from first_page instead of location, we could squeeze it into page->mapping because the 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 +...

Zsmalloc stores first free object's position into first_page->freelist in each zspage. If we change it with object index from first_page instead of location, we could squeeze it into page->mapping because the number of bit we need to store offset is at most 11bit. Signed-off-by: Minchan Kim <minchan at kernel.org> --- mm/zsmalloc.c | 159 +++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 96 insertions(+), 63 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 954e8758a78d..e23cd3b2dd71 100644 --- a/mm/zsmalloc.c +...

Hi. I experimented a bit with collecting entropy from the time it takes for device_attach() to run (in CPU cycles). It seems that those times have enough variation that we can use it for entropy harvesting. It happens even before root is mounted, so pretty early. On the machine I'm testing it, which has minimal kernel plus NIC driver I see 75 device_attach() calls. I'm being very careful

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.

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.