On Sat, Feb 19, 2022 at 08:51:59AM +0800, Baoquan He wrote: > Let's replace it with other ways. This is the first step towards > removing dma-kmalloc support in kernel (Means that if everyting > is going well, we can't use kmalloc(GFP_DMA) to allocate buffer in the > future). ... > > Next, plan to investigate how we should handle places as below. We > firstly need figure out whether they really need buffer from ZONE_DMA. > If yes, how to change them with other ways. This need help from > maintainers, experts from sub-components and code contributors or anyone > knowing them well. E.g s390 and crypyto, we need guidance and help. > > 1) Kmalloc(GFP_DMA) in s390 platform, under arch/s390 and drivers/s390; So, s390 partially requires GFP_DMA allocations for memory areas which are required by the hardware to be below 2GB. There is not necessarily a device associated when this is required. E.g. some legacy "diagnose" calls require buffers to be below 2GB. How should something like this be handled? I'd guess that the dma_alloc API is not the right thing to use in such cases. Of course we could say, let's waste memory and use full pages instead, however I'm not sure this is a good idea. s390 drivers could probably converted to dma_alloc API, even though that would cause quite some code churn. > For this first patch series, thanks to Hyeonggon for helping > reviewing and great suggestions on patch improving. We will work > together to continue the next steps of work. > > Any comment, thought, or suggestoin is welcome and appreciated, > including but not limited to: > 1) whether we should remove dma-kmalloc support in kernel(); The question is: what would this buy us? As stated above I'd assume this comes with quite some code churn, so there should be a good reason to do this.
