On 2/27/22 04:49, Hyeonggon Yoo wrote: > I think it's not traces of "currently free objects" > because index bit of free objects are set in obj_map bitmap? Hm right, thanks. > It's weird but it's traces of allocated objects that have been freed at > least once (or <not available>) > > I think we can fix the code or doc? For now I'll fix the doc. Not clear to me myself what's the best usecase for free_traces file. For alloc_traces it's clearly debugging memory leaks. Freeing traces are most useful when a bug is detected and they are dumped in dmesg. The debugfs file might be just for a rough idea where freeing usually happens. > Please tell me if I'm missing something :) > >> + Information in the output: >> + Number of objects, freeing function, minimal/average/maximal jiffies since free, >> + pid range of the freeing processes, cpu mask of freeing cpus, and stack trace. >> + >> + Example::: >> + >> + 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1 >> + kfree+0x2db/0x420 >> + acpi_ut_update_ref_count+0x6a6/0x782 >> + acpi_ut_update_object_reference+0x1ad/0x234 >> + acpi_ut_remove_reference+0x7d/0x84 >> + acpi_rs_get_prt_method_data+0x97/0xd6 >> + acpi_get_irq_routing_table+0x82/0xc4 >> + acpi_pci_irq_find_prt_entry+0x8e/0x2e0 >> + acpi_pci_irq_lookup+0x3a/0x1e0 >> + acpi_pci_irq_enable+0x77/0x240 >> + pcibios_enable_device+0x39/0x40 >> + do_pci_enable_device.part.0+0x5d/0xe0 >> + pci_enable_device_flags+0xfc/0x120 >> + pci_enable_device+0x13/0x20 >> + virtio_pci_probe+0x9e/0x170 >> + local_pci_probe+0x48/0x80 >> + pci_device_probe+0x105/0x1c0 >> + > > Everything else looks nice! > >> Christoph Lameter, May 30, 2007 >> Sergey Senozhatsky, October 23, 2015 >> -- >> 2.35.1 >> >> >
