|
loop shuo.tian 发件人: Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx>
发送时间: 2024年9月27日 16:01 收件人: zhang fangzheng 抄送: Vlastimil Babka; 张方正 (Fangzheng Zhang); Christoph Lameter; Pekka Enberg; David Rientjes; Joonsoo Kim; Andrew Morton; Roman Gushchin; Greg KH; linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; tkjos@xxxxxxxxxx; 韩玉明 (Yuming Han); Suren Baghdasaryan; Kent Overstreet 主题: Re: [PATCH 0/2] Introduce panic function when slub leaks 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Fri, Sep 27, 2024 at 4:28 PM zhang fangzheng <fangzheng.zhang1003@xxxxxxxxx> wrote: > > On Thu, Sep 26, 2024 at 8:30 PM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > > > 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? > > Ok, this is because the current consideration is to specifically > track the memory usage of the slab module. > In the stability test, ie, monkey test, > the anr or reboot problem occurs, there is a high probability > that the slab occupancy is high when it comes to memory analysis. > In addition to directly monitoring leaks in the allocation path, it is > also convenient to record the allocation stack information > when an exception occurs. [+Cc Memory Allocation Profiling maintainers] For recording allocation information, I think CONFIG_MEM_ALLOC_PROFILING [1] [2] may be used to track allocation sites that contribute to memory leaks, instead of making the kernel panic or printing WARNING? .....Or with higher overhead, slub_debug=U [3] if it is not meant to be run on production. [1] https://docs.kernel.org/mm/allocation-profiling.html [2] https://lwn.net/Articles/974380 [3] https://docs.kernel.org/mm/slub.html#debugfs-files-for-slub Best, Hyeonggon > > 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 > > This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions. 本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。 |
