On Wed, 27 Mar 2019 15:19:51 +0100, Michal Hocko wrote: > > On Wed 27-03-19 14:51:17, Takashi Iwai wrote: > > On Wed, 27 Mar 2019 12:47:30 +0100, > > Michal Hocko wrote: > > > > > > On Wed 27-03-19 10:29:58, Takashi Iwai wrote: > > > > snd_malloc_pages() and snd_free_pages() are merely thin wrappers of > > > > the standard page allocator / free functions. Even the arguments are > > > > compatible with some standard helpers, so there is little merit of > > > > keeping these wrappers. > > > > > > > > This patch replaces the all existing callers of snd_malloc_pages() and > > > > snd_free_pages() with the direct calls of the standard helper > > > > functions. In this version, we use a recently introduced one, > > > > alloc_pages_exact(), which suits better than the old > > > > snd_malloc_pages() implementation for our purposes. Then we can avoid > > > > the waste of pages by alignment to power-of-two. > > > > > > > > Since alloc_pages_exact() does split pages, we need no longer > > > > __GFP_COMP flag; or better to say, we must not pass __GFP_COMP to > > > > alloc_pages_exact(). So the former unconditional addition of > > > > __GFP_COMP flag in snd_malloc_pages() is dropped, as well as in most > > > > other places. > > > > > > I haven't checked all the callers but the replacement makes sense to me. > > > I am just wondering whether there is any hard requireemet to have all > > > those requests to be physically contiguous or kvmalloc would suit them > > > better. > > > > Most of callers are supposed to allocate buffers that can be also > > mmapped to user-space, so kvmalloc() won't work. So, the explicit > > page allocations are on purpose. > > OK, I see. There is a facility to remap vmalloc pages to userspace > (remap_vmalloc_range_partial) but I can see why you do not want to > change the code around. Thanks, it's good to know the remap_vmalloc_range*(). Currently we're mapping vmalloced buffer via vm fault calls. > From the snd_malloc_pages->alloc_pages_exact point of view (I haven't > checked all the callers) feel free to add > Acked-by: Michal Hocko <mhocko@xxxxxxxx> Added. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
