Re: Block layer use of __GFP flags

2018-04-09 Thread Michal Hocko
On Mon 09-04-18 15:03:45, Bart Van Assche wrote: > On Mon, 2018-04-09 at 11:00 +0200, Michal Hocko wrote: > > On Mon 09-04-18 04:46:22, Bart Van Assche wrote: > > [...] > > [...] > > > diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c > > > index ad8a125defdd..3ddb464b72e6 100644 > > > --- a

Re: Block layer use of __GFP flags

2018-04-09 Thread Bart Van Assche
On Mon, 2018-04-09 at 01:26 -0700, Christoph Hellwig wrote: > On Mon, Apr 09, 2018 at 08:53:49AM +0200, Hannes Reinecke wrote: > > Why don't you fold the 'flags' argument into the 'gfp_flags', and drop > > the 'flags' argument completely? > > Looks a bit pointless to me, having two arguments denoti

Re: Block layer use of __GFP flags

2018-04-09 Thread Matthew Wilcox
On Mon, Apr 09, 2018 at 01:26:50AM -0700, Christoph Hellwig wrote: > On Mon, Apr 09, 2018 at 08:53:49AM +0200, Hannes Reinecke wrote: > > Why don't you fold the 'flags' argument into the 'gfp_flags', and drop > > the 'flags' argument completely? > > Looks a bit pointless to me, having two arguments

Re: Block layer use of __GFP flags

2018-04-09 Thread Bart Van Assche
On Mon, 2018-04-09 at 11:00 +0200, Michal Hocko wrote: > On Mon 09-04-18 04:46:22, Bart Van Assche wrote: > [...] > [...] > > diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c > > index ad8a125defdd..3ddb464b72e6 100644 > > --- a/drivers/ide/ide-pm.c > > +++ b/drivers/ide/ide-pm.c > > @@ -91

Re: Block layer use of __GFP flags

2018-04-09 Thread Michal Hocko
On Mon 09-04-18 04:46:22, Bart Van Assche wrote: [...] [...] > diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c > index ad8a125defdd..3ddb464b72e6 100644 > --- a/drivers/ide/ide-pm.c > +++ b/drivers/ide/ide-pm.c > @@ -91,7 +91,7 @@ int generic_ide_resume(struct device *dev) > > mems

Re: Block layer use of __GFP flags

2018-04-09 Thread Christoph Hellwig
On Mon, Apr 09, 2018 at 08:53:49AM +0200, Hannes Reinecke wrote: > Why don't you fold the 'flags' argument into the 'gfp_flags', and drop > the 'flags' argument completely? > Looks a bit pointless to me, having two arguments denoting basically > the same ... Wrong way around. gfp_flags doesn't re

Re: Block layer use of __GFP flags

2018-04-08 Thread Hannes Reinecke
On Mon, 9 Apr 2018 04:46:22 + "Bart Van Assche" wrote: > On Sun, 2018-04-08 at 12:08 -0700, Matthew Wilcox wrote: > > On Sun, Apr 08, 2018 at 04:40:59PM +, Bart Van Assche wrote: > > > Do you perhaps want me to prepare a patch that makes > > > blk_get_request() again respect the full gf

Re: Block layer use of __GFP flags

2018-04-08 Thread Bart Van Assche
On Sun, 2018-04-08 at 12:08 -0700, Matthew Wilcox wrote: > On Sun, Apr 08, 2018 at 04:40:59PM +, Bart Van Assche wrote: > > Do you perhaps want me to prepare a patch that makes blk_get_request() again > > respect the full gfp mask passed as third argument to blk_get_request()? > > I think that

Re: Block layer use of __GFP flags

2018-04-08 Thread Matthew Wilcox
On Sun, Apr 08, 2018 at 04:40:59PM +, Bart Van Assche wrote: > __GFP_KSWAPD_RECLAIM wasn't stripped off on purpose for non-atomic > allocations. That was an oversight. OK, good. > Do you perhaps want me to prepare a patch that makes blk_get_request() again > respect the full gfp mask passed

Re: Block layer use of __GFP flags

2018-04-08 Thread Bart Van Assche
On Sat, 2018-04-07 at 23:54 -0700, Matthew Wilcox wrote: > Please explain: > > commit 6a15674d1e90917f1723a814e2e8c949000440f7 > Author: Bart Van Assche > Date: Thu Nov 9 10:49:54 2017 -0800 > > block: Introduce blk_get_request_flags() > > A side effect of this patch is that the G

Block layer use of __GFP flags

2018-04-07 Thread Matthew Wilcox
Please explain: commit 6a15674d1e90917f1723a814e2e8c949000440f7 Author: Bart Van Assche Date: Thu Nov 9 10:49:54 2017 -0800 block: Introduce blk_get_request_flags() A side effect of this patch is that the GFP mask that is passed to several allocation functions in the legacy b