On Fri 25-05-18 05:00:44, Matthew Wilcox wrote: > On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote: > > > ie if we had more, > > > could we solve our pain by making them more generic? > > > > Well, if you have more you will consume more bits in the struct pages, > > right? > > Not necessarily ... the zone number is stored in the struct page > currently, so either two or three bits are used right now. In my > proposal, one can infer the zone of a page from its PFN, except for > ZONE_MOVABLE. So we could trim down to just one bit per struct page > for 32-bit machines while using 3 bits on 64-bit machines, where there > is plenty of space. Just be warned that page_zone is called from many hot paths. I am not sure adding something more complex there is going to fly. > > > it more-or-less sucks that the devices with 28-bit DMA limits are forced > > > to allocate from the low 16MB when they're perfectly capable of using the > > > low 256MB. > > > > Do we actually care all that much about those? If yes then we should > > probably follow the ZONE_DMA (x86) path and use a CMA region for them. > > I mean most devices should be good with very limited addressability or > > below 4G, no? > > Sure. One other thing I meant to mention was the media devices > (TV capture cards and so on) which want a vmalloc_32() allocation. > On 32-bit machines right now, we allocate from LOWMEM, when we really > should be allocating from the 1GB-4GB region. 32-bit machines generally > don't have a ZONE_DMA32 today. Well, _I_ think that vmalloc on 32b is just lost case... -- Michal Hocko SUSE Labs
