On 28/04/17 11:36, Michal Hocko wrote: > I didn't read this thoughly yet because I will be travelling shortly ok, thanks for bearing with me =) > but > this point alone just made ask, because it seems there is some > misunderstanding It is possible, so far I did some changes, but I have not completed the whole conversion. > On Fri 28-04-17 11:04:27, Igor Stoppa wrote: > [...] >> * if one is happy to have a 64bits type, allow for as many zones as >> it's possible to fit, or anyway more than what is possible with >> the 32 bit mask. > > zones are currently placed in struct page::flags. And that already is > 64b size on 64b arches. Ok, the issues I had so fare were related to the enum for zones being treated as 32b. > And we do not really have any room spare there. > We encode page flags, zone id, numa_nid/sparse section_nr there. How can > you add more without enlarging the struct page itself or using external > means to store the same information (page_ext comes to mind)? Then I'll be conservative and assume I can't, unless I can prove otherwise. There is still the possibility I mentioned of loosely coupling DMA, DMA32 and HIGHMEM with the bits currently reserved for them, right? If my system doesn't use those zones as such, because it doesn't have/need them, those bits are wasted for me. Otoh someone else is probably not interested in what I'm after but needs one or more of those zones. Making the meaning of the bits configurable should still be a viable option. It's not altering their amount, just their purpose on a specific build. > Even if > the later would be possible then note thatpage_zone() is used in many > performance sensitive paths and making it perform well with special > casing would be far from trivial. If the solution I propose is acceptable, I'm willing to bite the bullet and go for implementing the conversion. In my case I really would like to be able to use kmalloc, because it would provide an easy path to convert also other portions of the kernel, besides SE Linux. I suspect I would encounter overall far less resistance if the type of change I propose is limited to: s/GFP_KERNEL/GFP_LOCKABLE/ And if I can guarrantee that GFP_LOCKABLE falls back to GFP_KERNEL when the "lockable" feature is not enabled. -- thanks, igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
