Re: [Lsf-pc] [LSF/MM ATTEND] memory allocation scope

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 15-02-18 17:02:41, Michal Hocko wrote:
> On Thu 15-02-18 07:57:37, James Bottomley wrote:
> > On Thu, 2018-02-15 at 15:48 +0100, Michal Hocko wrote:
> > > On Wed 14-02-18 16:51:53, Goldwyn Rodrigues wrote:
> > > > 
> > > > 
> > > > Discussion with the memory folks towards scope based allocation
> > > > I am working on converting some of the GFP_NOFS memory allocation
> > > > calls to new scope API [1]. While other allocation types (noio,
> > > > nofs, noreclaim) are covered. Are there plans for identifying scope
> > > > of GFP_ATOMIC allocations? This should cover most (if not all) of
> > > > the allocation scope.
> > > 
> > > There was no explicit request for that but I can see how some users
> > > might want it. I would have to double check but maybe this would
> > > allow vmalloc(GFP_ATOMIC). There were some users but most of them
> > > could have been changed in some way so the motivation is not very
> > > large.
> > 
> > We have to be careful about that: most GFP_ATOMIC allocations are in
> > drivers and may be for DMA'able memory.  We can't currently use vmalloc
> > memory for DMA to kernel via block because bio_map_kern() uses
> > virt_to_page() which assumes offset mapping.  The latter is fixable,
> > obviously, but is it worth fixing?  Very few GFP_ATOMIC allocations in
> > drivers will be for large chunks.
> 
> Yes this might be not worth bothering. But from the conceptual POV
> GFP_ATOMIC resp. GFP_NOWAIT is very often a scope context - IRQs,
> preemption or RCU. So protecting all allocations from that context makes
> some sense. Not sure this is really worth spending another context bit
> though.

And just to clarify why I've mentioned vmalloc explicitly. vmalloc
simply ignores the given gfp flags for pte allocations (those are
hardcoded GFP_KERNEL) and that is why it is not generally suitable for
atomic contexts. Maybe there are other obstacles (sleeping locks) but
scope gfp would solve at least the pte allocation side.
-- 
Michal Hocko
SUSE Labs



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux