search for: zs_register_shrink

...gt;> I only see two shrinker flags (NUMA_AWARE and MEMCG_AWARE), and >> they seem not related to that. >> >> Where is vb->shrinker.flags initialized? > > Is that mandatory to be initialized? Of course. ;-) > I find it's not initialized in most shrinkers (e.g. zs_register_shrinker, huge_zero_page_shrinker). Because most shrinkers are "statically initialized (which means that unspecified fields are implicitly zero-cleared)" or "dynamically allocated with __GFP_ZERO or zero-cleared using memset() (which means that all fields are once zero-cleared)". And...

On 2018/08/06 18:56, Wei Wang wrote: > On 08/03/2018 08:11 PM, Tetsuo Handa wrote: >> On 2018/08/03 17:32, Wei Wang wrote: >>> +static int virtio_balloon_register_shrinker(struct virtio_balloon *vb) >>> +{ >>> +??? vb->shrinker.scan_objects = virtio_balloon_shrinker_scan; >>> +??? vb->shrinker.count_objects = virtio_balloon_shrinker_count;

On 2018/08/06 18:56, Wei Wang wrote: > On 08/03/2018 08:11 PM, Tetsuo Handa wrote: >> On 2018/08/03 17:32, Wei Wang wrote: >>> +static int virtio_balloon_register_shrinker(struct virtio_balloon *vb) >>> +{ >>> +??? vb->shrinker.scan_objects = virtio_balloon_shrinker_scan; >>> +??? vb->shrinker.count_objects = virtio_balloon_shrinker_count;

...here in the code that would complain it? > > I only see two shrinker flags (NUMA_AWARE and MEMCG_AWARE), and > they seem not related to that. > > Where is vb->shrinker.flags initialized? Is that mandatory to be initialized? I find it's not initialized in most shrinkers (e.g. zs_register_shrinker, huge_zero_page_shrinker). Best, Wei

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.