Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 04/27/2017 03:35 PM, Michal Hocko wrote: > On Thu 27-04-17 15:16:47, Igor Stoppa wrote: >> On 26/04/17 18:29, Igor Stoppa wrote: >> >>> On 26/04/17 17:47, Michal Hocko wrote: >> >> [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed here so I suspect you have

Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 04/27/2017 03:35 PM, Michal Hocko wrote: > On Thu 27-04-17 15:16:47, Igor Stoppa wrote: >> On 26/04/17 18:29, Igor Stoppa wrote: >> >>> On 26/04/17 17:47, Michal Hocko wrote: >> >> [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed here so I suspect you have

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 28/04/17 10:43, Igor Stoppa wrote: [...] > I'm writing an alternative different proposal, let's call it last attempt. > > Should be ready in a few minutes. Here: http://marc.info/?l=linux-mm=149336675129967=2 -- thanks, igor

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 28/04/17 10:43, Igor Stoppa wrote: [...] > I'm writing an alternative different proposal, let's call it last attempt. > > Should be ready in a few minutes. Here: http://marc.info/?l=linux-mm=149336675129967=2 -- thanks, igor

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 28/04/17 10:40, Michal Hocko wrote: > Do not add a new zone, really. What you seem to be looking for is an > allocator on top of the page/memblock allocator which does write > protection on top. I understand that you would like to avoid object > management duplication but I am not really

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 28/04/17 10:40, Michal Hocko wrote: > Do not add a new zone, really. What you seem to be looking for is an > allocator on top of the page/memblock allocator which does write > protection on top. I understand that you would like to avoid object > management duplication but I am not really

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Thu 27-04-17 17:06:05, Igor Stoppa wrote: > > > On 27/04/17 16:41, Michal Hocko wrote: > > On Wed 26-04-17 18:29:08, Igor Stoppa wrote: > > [...] > >> If you prefer to have this patch only as part of the larger patchset, > >> I'm also fine with it. > > > > I agree that the situation is not

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Thu 27-04-17 17:06:05, Igor Stoppa wrote: > > > On 27/04/17 16:41, Michal Hocko wrote: > > On Wed 26-04-17 18:29:08, Igor Stoppa wrote: > > [...] > >> If you prefer to have this patch only as part of the larger patchset, > >> I'm also fine with it. > > > > I agree that the situation is not

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 27/04/17 16:41, Michal Hocko wrote: > On Wed 26-04-17 18:29:08, Igor Stoppa wrote: > [...] >> If you prefer to have this patch only as part of the larger patchset, >> I'm also fine with it. > > I agree that the situation is not ideal. If a larger set of changes > would benefit from this

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 27/04/17 16:41, Michal Hocko wrote: > On Wed 26-04-17 18:29:08, Igor Stoppa wrote: > [...] >> If you prefer to have this patch only as part of the larger patchset, >> I'm also fine with it. > > I agree that the situation is not ideal. If a larger set of changes > would benefit from this

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Wed 26-04-17 18:29:08, Igor Stoppa wrote: [...] > If you prefer to have this patch only as part of the larger patchset, > I'm also fine with it. I agree that the situation is not ideal. If a larger set of changes would benefit from this change then it would clearly add arguments... > Also, if

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Wed 26-04-17 18:29:08, Igor Stoppa wrote: [...] > If you prefer to have this patch only as part of the larger patchset, > I'm also fine with it. I agree that the situation is not ideal. If a larger set of changes would benefit from this change then it would clearly add arguments... > Also, if

Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Thu 27-04-17 15:16:47, Igor Stoppa wrote: > On 26/04/17 18:29, Igor Stoppa wrote: > > > On 26/04/17 17:47, Michal Hocko wrote: > > [...] > > >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed > >> here so I suspect you have based your change on the Linus tree. > > > I

Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Thu 27-04-17 15:16:47, Igor Stoppa wrote: > On 26/04/17 18:29, Igor Stoppa wrote: > > > On 26/04/17 17:47, Michal Hocko wrote: > > [...] > > >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed > >> here so I suspect you have based your change on the Linus tree. > > > I

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it, I was using master,

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it, I was using master,

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it, I was using master,

Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 18:29, Igor Stoppa wrote: > On 26/04/17 17:47, Michal Hocko wrote: [...] >> Also the current mm tree has ___GFP_NOLOCKDEP which is not addressed >> here so I suspect you have based your change on the Linus tree. > I used your tree from kernel.org I found it, I was using master,

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 17:47, Michal Hocko wrote: > On Wed 26-04-17 16:35:49, Igor Stoppa wrote: >> The bitmasks used for ___GFP_xxx can be defined in terms of an enum, >> which doesn't require manual updates to its values. > > GFP masks are rarely updated so why is this worth doing? I have plans for

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On 26/04/17 17:47, Michal Hocko wrote: > On Wed 26-04-17 16:35:49, Igor Stoppa wrote: >> The bitmasks used for ___GFP_xxx can be defined in terms of an enum, >> which doesn't require manual updates to its values. > > GFP masks are rarely updated so why is this worth doing? I have plans for

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Wed 26-04-17 16:35:49, Igor Stoppa wrote: > The bitmasks used for ___GFP_xxx can be defined in terms of an enum, > which doesn't require manual updates to its values. GFP masks are rarely updated so why is this worth doing? > As bonus, __GFP_BITS_SHIFT is automatically kept consistent. this

Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

On Wed 26-04-17 16:35:49, Igor Stoppa wrote: > The bitmasks used for ___GFP_xxx can be defined in terms of an enum, > which doesn't require manual updates to its values. GFP masks are rarely updated so why is this worth doing? > As bonus, __GFP_BITS_SHIFT is automatically kept consistent. this

[PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

The bitmasks used for ___GFP_xxx can be defined in terms of an enum, which doesn't require manual updates to its values. As bonus, __GFP_BITS_SHIFT is automatically kept consistent. Signed-off-by: Igor Stoppa --- include/linux/gfp.h | 82

[PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks

The bitmasks used for ___GFP_xxx can be defined in terms of an enum, which doesn't require manual updates to its values. As bonus, __GFP_BITS_SHIFT is automatically kept consistent. Signed-off-by: Igor Stoppa --- include/linux/gfp.h | 82 +++-- 1