On 9/25/24 15:18, Hyeonggon Yoo wrote: > On Wed, Sep 25, 2024 at 12:23 PM Fangzheng Zhang > <fangzheng.zhang@xxxxxxxxxx> wrote: >> >> Hi all, > > Hi Fangzheng, > >> A method to detect slub leaks by monitoring its usage in real time >> on the page allocation path of the slub. When the slub occupancy >> exceeds the user-set value, it is considered that the slub is leaking >> at this time > > I'm not sure why this should be a kernel feature. Why not write a user > script that parses > MemTotal: and Slab: part of /proc/meminfo file and generates a log > entry or an alarm? Yes very much agreed. It seems rather arbitrary. Why slab, why not any other kernel-specific counter in /proc/meminfo? Why include NR_SLAB_RECLAIMABLE_B when that's used by caches with shrinkers? A userspace solution should be straightforward and universal - easily configurable for different scenarios. >> and a panic operation will be triggered immediately. > > I don't think it would be a good idea to panic unnecessarily. > IMO it is not proper to panic when the kernel can still run. Yes these days it's practically impossible to add a BUG_ON() for more serious conditions than this. Please don't post new versions addressing specific implementation details until this fundamental issue is addressed. Thanks, Vlastimil > Any thoughts? > > Thanks, > Hyeonggon
