Re: [PATCH v3 28/49] dm zoned: dynamically allocate the dm-zoned-meta shrinker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2023/7/27 18:20, Damien Le Moal wrote:
On 7/27/23 17:55, Qi Zheng wrote:
           goto err;
       }
   +    zmd->mblk_shrinker->count_objects = dmz_mblock_shrinker_count;
+    zmd->mblk_shrinker->scan_objects = dmz_mblock_shrinker_scan;
+    zmd->mblk_shrinker->seeks = DEFAULT_SEEKS;
+    zmd->mblk_shrinker->private_data = zmd;
+
+    shrinker_register(zmd->mblk_shrinker);

I fail to see how this new shrinker API is better... Why isn't there a
shrinker_alloc_and_register() function ? That would avoid adding all this code
all over the place as the new API call would be very similar to the current
shrinker_register() call with static allocation.

In some registration scenarios, memory needs to be allocated in advance.
So we continue to use the previous prealloc/register_prepared()
algorithm. The shrinker_alloc_and_register() is just a helper function
that combines the two, and this increases the number of APIs that
shrinker exposes to the outside, so I choose not to add this helper.

And that results in more code in many places instead of less code + a simple
inline helper in the shrinker header file... So not adding that super simple

It also needs to be exported to the driver for use.

helper is not exactly the best choice in my opinion.

Hm, either one is fine for me. If no one else objects, I can add this
helper. ;)





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux