Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1303923 > unrolled thread

Re: [PATCH v2 9/9] mm, oom: print symbolic gfp_flags in oom warning

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 9/9] mm, oom: print symbolic gfp_flags in oom  warning David Rientjes <rientjes@google.com> - 2016-01-07 22:30 +0100
    Re: [PATCH v2 9/9] mm, oom: print symbolic gfp_flags in oom warning Vlastimil Babka <vbabka@suse.cz> - 2016-01-08 12:40 +0100

#1303923 — Re: [PATCH v2 9/9] mm, oom: print symbolic gfp_flags in oom warning

On Tue, 24 Nov 2015, Vlastimil Babka wrote:

> It would be useful to translate gfp_flags into string representation when
> printing in case of an OOM, especially as the flags have been undergoing some
> changes recently and the script ./scripts/gfp-translate needs a matching source
> version to be accurate.
> 
> Example output:
> 
> a.out invoked oom-killer: order=0, oom_score_adj=0, gfp_mask=0x24280ca(GFP_HIGHUSER_MOVABLE|GFP_ZERO)
> 

Is there a way that we can keep the order of the fields so that anything 
parsing the kernel log for oom kills doesn't break?  The messages printed 
to the kernel log are the only (current) way to determine that the kernel 
killed something so we should be careful not to break anything parsing 
them, and this is a common line to look for.

[toc] | [next] | [standalone]

#1304416 — Re: [PATCH v2 9/9] mm, oom: print symbolic gfp_flags in oom warning

On 01/07/2016 10:29 PM, David Rientjes wrote:
> On Tue, 24 Nov 2015, Vlastimil Babka wrote:
>
>> It would be useful to translate gfp_flags into string representation when
>> printing in case of an OOM, especially as the flags have been undergoing some
>> changes recently and the script ./scripts/gfp-translate needs a matching source
>> version to be accurate.
>>
>> Example output:
>>
>> a.out invoked oom-killer: order=0, oom_score_adj=0, gfp_mask=0x24280ca(GFP_HIGHUSER_MOVABLE|GFP_ZERO)
>>
>
> Is there a way that we can keep the order of the fields so that anything
> parsing the kernel log for oom kills doesn't break?

Yes, this is possible with the new printk handling of flags, please look 
at v3:
http://marc.info/?l=linux-mm&m=145042944710510&w=2

There I changed the print just to have order first and gfp_mask next, as 
it seemed more logical. But it doesn't need to be that way and I can 
post V4 keeping the original order of variables. But do you think the 
flags expansion is safe to add there, or should I put it on separate line?

Thanks

> The messages printed
> to the kernel log are the only (current) way to determine that the kernel
> killed something so we should be careful not to break anything parsing
> them, and this is a common line to look for.
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web