Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1490644
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] mm: warn about allocations which stall for too long |
| Date | 2016-09-24 15:20 +0200 |
| Message-ID | <skV21-1qQ-1@gated-at.bofh.it> (permalink) |
| References | <sktS9-1fi-5@gated-at.bofh.it> <skCC6-6Ov-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 24/09/16 03:34, Dave Hansen wrote:
> On 09/23/2016 01:15 AM, Michal Hocko wrote:
>> + /* Make sure we know about allocations which stall for too long */
>> + if (!(gfp_mask & __GFP_NOWARN) && time_after(jiffies, alloc_start + stall_timeout)) {
>> + pr_warn("%s: page alloction stalls for %ums: order:%u mode:%#x(%pGg)\n",
>> + current->comm, jiffies_to_msecs(jiffies-alloc_start),
>> + order, gfp_mask, &gfp_mask);
>> + stall_timeout += 10 * HZ;
>> + dump_stack();
>> + }
>
> This would make an awesome tracepoint. There's probably still plenty of
> value to having it in dmesg, but the configurability of tracepoints is
> hard to beat.
An awesome tracepoint and a great place to trigger other tracepoints. With stall timeout
increasing every time, do we only care about the first instance when we exceeded stall_timeout?
Do we debug just that instance?
Balbir Singh.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] mm: warn about allocations which stall for too long Dave Hansen <dave.hansen@intel.com> - 2016-09-23 19:40 +0200
Re: [PATCH] mm: warn about allocations which stall for too long Balbir Singh <bsingharora@gmail.com> - 2016-09-24 15:20 +0200
Re: [PATCH] mm: warn about allocations which stall for too long Michal Hocko <mhocko@kernel.org> - 2016-09-26 10:20 +0200
Re: [PATCH] mm: warn about allocations which stall for too long Michal Hocko <mhocko@kernel.org> - 2016-09-26 10:20 +0200
csiph-web