Re: [PATCH] mm: hide per-cpu lists in output of show_mem()

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

 



On Wed, 25 Feb 2015, Konstantin Khlebnikov wrote:

> >> @@ -3220,11 +3229,10 @@ void show_free_areas(unsigned int filter)
> >>
> >>       printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n"
> >>               " active_file:%lu inactive_file:%lu isolated_file:%lu\n"
> >> -             " unevictable:%lu"
> >> -             " dirty:%lu writeback:%lu unstable:%lu\n"
> >> -             " free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n"
> >> +             " unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n"
> >> +             " slab_reclaimable:%lu slab_unreclaimable:%lu\n"
> >>               " mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
> >> -             " free_cma:%lu\n",
> >> +             " free:%lu free_pcp:%lu free_cma:%lu\n",
> >
> > Why is "free:" itself moved?  It is unlikely, but I could imagine that
> > this might break something that is parsing the kernel log and it would be
> > better to just leave it where it is and add "free_pcp:" after "free_cma:"
> > since this is extending the message.
> 
> I think it looks better at the beginning of new line, like this:
> 
> [   44.452955] Mem-Info:
> [   44.453233] active_anon:2307 inactive_anon:36 isolated_anon:0
> [   44.453233]  active_file:4120 inactive_file:4623 isolated_file:0
> [   44.453233]  unevictable:0 dirty:6 writeback:0 unstable:0
> [   44.453233]  slab_reclaimable:3500 slab_unreclaimable:7441
> [   44.453233]  mapped:2113 shmem:45 pagetables:292 bounce:0
> [   44.453233]  free:456891 free_pcp:12179 free_cma:0
> 
> In this order fields at each line have something in common.
> 
> I'll spend some some time playing with this code and oom log,
> maybe I'll try to turn whole output into table or something.
> 

The problem is that oom logs are usually parsed only from the kernel log, 
there's no other userspace trigger that we can use to identify when the 
kernel has killed something unless we wait() on every possible victim.  
It's typical for systems software to parse this information and unless 
there is a compelling reason other than "looks better", I think messages 
should only be extended rather than rearranged.

Admittedly, scraping the kernel log for oom kill events could certainly be 
done better with a userspace notification, but we currently lack that 
support in the kernel and there might be parsers out there in the wild 
that would break because of this.  I agree removing the pcp counters is 
good for this output, though, so I'd love to see that patch without this 
change.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]