Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1632590

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

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks
Date 2017-04-28 09:50 +0200
Message-ID <tB8P7-4n0-9@gated-at.bofh.it> (permalink)
References (1 earlier) <tAvkJ-2S4-1@gated-at.bofh.it> <tAwqu-3Ay-25@gated-at.bofh.it> <tAxcS-4ap-13@gated-at.bofh.it> <tARXY-1hZ-9@gated-at.bofh.it> <tAShj-1ET-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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 ideal. If a larger set of changes
> > would benefit from this change then it would clearly add arguments...
> 
> Ok, then I'll send it out as part of the larger RFC set.
> 
> 
> >> Also, if you could reply to [1], that would be greatly appreciated.
> > 
> > I will try to get to it but from a quick glance, yet-another-zone will
> > hit a lot of opposition...
> 
> The most basic questions, that I hope can be answered with Yes/No =) are:
> 
> - should a new zone be added after DMA32?
> 
> - should I try hard to keep the mask fitting a 32bit word - at least for
> hose who do not use the new zone - or is it ok to just stretch it to 64
> bits?

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 sure how much you can re-use
what slab allocators do already, anyway. I will respond to the original
thread to not mix things together.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-26 15:40 +0200
  Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Michal Hocko <mhocko@kernel.org> - 2017-04-26 16:50 +0200
    Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-26 17:40 +0200
      Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding  of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-27 14:20 +0200
        Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove  hardcoding of ___GFP_xxx bitmasks Michal Hocko <mhocko@kernel.org> - 2017-04-27 15:40 +0200
          Re: Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove  hardcoding of ___GFP_xxx bitmasks Vlastimil Babka <vbabka@suse.cz> - 2017-05-10 17:30 +0200
      Question on ___GFP_NOLOCKDEP - Was: Re: [PATCH 1/1] Remove hardcoding  of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-27 14:30 +0200
      Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Michal Hocko <mhocko@kernel.org> - 2017-04-27 15:50 +0200
        Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-27 16:10 +0200
          Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Michal Hocko <mhocko@kernel.org> - 2017-04-28 09:50 +0200
            Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-28 09:50 +0200
              Re: [PATCH 1/1] Remove hardcoding of ___GFP_xxx bitmasks Igor Stoppa <igor.stoppa@huawei.com> - 2017-04-28 10:20 +0200

csiph-web