[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [External] Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD
From: owner-linux-mm@xxxxxxxxx [mailto:owner-linux-mm@xxxxxxxxx] On Behalf Of Michal Hocko Sent: Monday, May 28, 2018 9:38 PM > > In my opinion, originally there shouldn't be such many wrong > > combinations of these bottom 3 bits. For any user, whether or > > driver and fs, they should make a decision that which zone is they > > preferred. Matthew's idea is great, because with it the user must > > offer an unambiguous flag to gfp zone bits. > > Well, I would argue that those shouldn't really care about any zones at > all. All they should carea bout is whether they really need a low mem > zone (aka directly accessible to the kernel), highmem or they are the > allocation is generally movable. Mixing zones into the picture just > makes the whole thing more complicated and error prone. Dear Michal, I don't quite understand that. I think those, mostly drivers, need to get the correct zone they want. ZONE_DMA32 is an example, if drivers can be satisfied with a low mem zone, why they mark the gfp flags as 'GFP_KERNEL|__GFP_DMA32'? GFP_KERNEL is enough to make sure a directly accessible low mem, but it is obvious that they want to get a DMA accessible zone below 4G. > This should be a part of the changelog. Please note that you should > provide some number if you claim performance benefits. The complexity > will always be subjective. Sure, I will post them to changelog with next version of patches. Sincerely, Huaisheng Ye _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |