Messages in this thread | | | Date | Tue, 28 Nov 2023 11:07:18 +0100 | From | Michal Hocko <> | Subject | Re: [PATCH 4/7] mm: Centralize & improve oom reporting in show_mem.c |
| |
On Wed 22-11-23 18:25:09, Kent Overstreet wrote: [...] > 00177 Shrinkers: > 00177 super_cache_scan: objects: 127 > 00177 super_cache_scan: objects: 106 > 00177 jbd2_journal_shrink_scan: objects: 32 > 00177 ext4_es_scan: objects: 32 > 00177 bch2_btree_cache_scan: objects: 8 > 00177 nr nodes: 24 > 00177 nr dirty: 0 > 00177 cannibalize lock: 0000000000000000 > 00177 > 00177 super_cache_scan: objects: 8 > 00177 super_cache_scan: objects: 1
It would be really great to provide an example on how these numbers are useful for the oom evaluation.
[...] > @@ -423,4 +426,21 @@ void __show_mem(unsigned int filter, nodemask_t *nodemask, int max_zone_idx) > #ifdef CONFIG_MEMORY_FAILURE > printk("%lu pages hwpoisoned\n", atomic_long_read(&num_poisoned_pages)); > #endif > + > + buf = kmalloc(4096, GFP_ATOMIC);
I really do not think we want to allow allocations from the OOM context. Is there any reason why this cannot be a statically allocated buffer?
> + if (buf) { > + struct seq_buf s; > + > + printk("Unreclaimable slab info:\n"); > + seq_buf_init(&s, buf, 4096); > + dump_unreclaimable_slab(&s); > + printk("%s", seq_buf_str(&s)); > + > + printk("Shrinkers:\n"); > + seq_buf_init(&s, buf, 4096); > + shrinkers_to_text(&s); > + printk("%s", seq_buf_str(&s)); > + > + kfree(buf); > + } > } -- Michal Hocko SUSE Labs
| |