On Tue 27-09-16 21:57:26, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > > > ) rather than by line number, and surround __warn_memalloc_stall()
> > > > > call with
> > > > > mutex in order to serialize warning messages because it is possible
> > > > > that
> > > > > multiple allocation requests
Michal Hocko wrote:
> > > > ) rather than by line number, and surround __warn_memalloc_stall() call
> > > > with
> > > > mutex in order to serialize warning messages because it is possible that
> > > > multiple allocation requests are stalling?
> > >
> > > we do not use any lock in warn_alloc_fai
On Sat 24-09-16 12:00:07, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 23-09-16 23:36:22, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned
> > > > int order,
> > > > else
> > > > no_progress
On Fri 23-09-16 10:34:01, 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
On Sat 24-09-16 23:19:04, Balbir Singh wrote:
>
>
> 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 +
> >> st
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 alloct
Michal Hocko wrote:
> On Fri 23-09-16 23:36:22, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned
> > > int order,
> > > else
> > > no_progress_loops++;
> > >
> > > + /* Make sure we know about allocations which s
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(%
On Fri 23-09-16 23:36:22, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int
> > order,
> > else
> > no_progress_loops++;
> >
> > + /* Make sure we know about allocations which stall for too long */
> > + i
Michal Hocko wrote:
> @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int
> order,
> else
> no_progress_loops++;
>
> + /* Make sure we know about allocations which stall for too long */
> + if (!(gfp_mask & __GFP_NOWARN) && time_after(jiffies, a
On Fri 23-09-16 16:44:26, Hillf Danton wrote:
> On Friday, September 23, 2016 4:32 PM, Michal Hocko wrote
> > On Fri 23-09-16 16:29:36, Hillf Danton wrote:
> > [...]
> > > > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned
> > > > int order,
> > > > else
> > > >
On Friday, September 23, 2016 4:32 PM, Michal Hocko wrote
> On Fri 23-09-16 16:29:36, Hillf Danton wrote:
> [...]
> > > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned
> > > int order,
> > > else
> > > no_progress_loops++;
> > >
> > > + /* Make sure we know about
>
> From: Michal Hocko
>
> Currently we do warn only about allocation failures but small
> allocations are basically nofail and they might loop in the page
> allocator for a long time. Especially when the reclaim cannot make
> any progress - e.g. GFP_NOFS cannot invoke the oom killer and rely o
On Fri 23-09-16 16:29:36, Hillf Danton wrote:
[...]
> > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int
> > order,
> > else
> > no_progress_loops++;
> >
> > + /* Make sure we know about allocations which stall for too long */
> > + if (!(gfp_mask & _
From: Michal Hocko
Currently we do warn only about allocation failures but small
allocations are basically nofail and they might loop in the page
allocator for a long time. Especially when the reclaim cannot make
any progress - e.g. GFP_NOFS cannot invoke the oom killer and rely on
a different c
15 matches
Mail list logo