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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to