Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-09 Thread Michal Hocko
On Wed 08-03-17 07:06:59, Christoph Hellwig wrote: > On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-09 Thread Michal Hocko
On Wed 08-03-17 07:06:59, Christoph Hellwig wrote: > On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for the given set > >

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Christoph Hellwig
On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Christoph Hellwig
On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations actually never

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Michal Hocko
On Wed 08-03-17 20:23:37, Tetsuo Handa wrote: > On 2017/03/08 0:48, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for the given set > > of flags.

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Michal Hocko
On Wed 08-03-17 20:23:37, Tetsuo Handa wrote: > On 2017/03/08 0:48, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for the given set > > of flags. This means that

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Tetsuo Handa
On 2017/03/08 0:48, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations actually never failed. >

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Tetsuo Handa
On 2017/03/08 0:48, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations actually never failed. > > Now that we

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Michal Hocko
On Tue 07-03-17 09:05:19, Darrick J. Wong wrote: > On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for the

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-08 Thread Michal Hocko
On Tue 07-03-17 09:05:19, Darrick J. Wong wrote: > On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > > so it relied on the default page allocator behavior for the given set > > of

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-07 Thread Darrick J. Wong
On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-07 Thread Darrick J. Wong
On Tue, Mar 07, 2017 at 04:48:42PM +0100, Michal Hocko wrote: > From: Michal Hocko > > KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently > so it relied on the default page allocator behavior for the given set > of flags. This means that small allocations actually never

[RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-07 Thread Michal Hocko
From: Michal Hocko KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently so it relied on the default page allocator behavior for the given set of flags. This means that small allocations actually never failed. Now that we have __GFP_RETRY_MAYFAIL flag which

[RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

2017-03-07 Thread Michal Hocko
From: Michal Hocko KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently so it relied on the default page allocator behavior for the given set of flags. This means that small allocations actually never failed. Now that we have __GFP_RETRY_MAYFAIL flag which works independently