On Mon, May 14, 2018 at 11:54:55PM +0300, Andy Shevchenko wrote: > According to [1] the GFP_DMA (and might be __GFP_DMA32, though it's > not explicitly listed, however dell-smbios.c is listed there) has some > memory allocator performance impac Performance analysis was done eons ago and back then there was a gain, no new performance analysis has been done but folks at LSFMM present didn't expect there to be any gains, so the whole GFP_DMA for x86 thing may just an aesthetics thing. Internally there are some things mm folks can also do long term to help with this and moving GFP_DMA to use CMA is one of it long term. However misuse of GFP_DMA for x86 drivers was acknowledged as likely being copy-and-paste mistakes. Use of GFP_DMA varies by architecture, and for x86 to only need it if you need lower 16 bit addresses. So just keep that in mind. Luis > and in 99.99% shows a buggy / old > hw / code. > > So, in PDx86 we have two files > > $ git grep -n GFP_DMA -- drivers/platform/x86/ > drivers/platform/x86/asus-wmi.c:343: input.pointer = > kzalloc(args.length, GFP_DMA | GFP_KERNEL); > drivers/platform/x86/dell-smbios-smm.c:138: buffer = (void > *)__get_free_page(GFP_KERNEL | GFP_DMA32); > > Looking to the ASuS related code I would conclude that the guy who > submitted a patch didn't investigate it properly and root cause left > unknown. So, would be nice to have someone with actual bug reproducer > to find a better solution. > > Dell case, since we have an active maintainer, can be clarified by > contributors and Dell representative here. > > Any (additional) thoughts with regard to the topic? > > [1]: https://lwn.net/Articles/753274/ > > -- > With Best Regards, > Andy Shevchenko > -- Do not panic
