Hi Jon and Sylwester, On Mon, Jul 29, 2013 at 09:16:44AM -0600, Jonathan Corbet wrote: > On Mon, 29 Jul 2013 13:27:12 +0200 > Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > > > You've gone to all this trouble to get a higher-order allocation so you'd > > > have fewer segments, then you undo it all by splitting things apart into > > > individual pages. Why? Clearly I'm missing something, this seems to > > > defeat the purpose of the whole exercise? > > > > Individual zero-order pages are required to get them mapped to userspace in > > mmap callback. > > Yeah, Ricardo explained that too. The right solution might be to fix that > problem rather than work around it, but I can see why one might shy at that > task! :) > > I do wonder, though, if an intermediate solution using huge pages might be > the best approach? That would get the number of segments down pretty far, > and using huge pages for buffers would reduce TLB pressure significantly > if the CPU is working through the data at all. Meanwhile, inserting huge > pages into the process's address space should work easily. Just a thought. My ack to that. And in the case of dma-buf the buffer doesn't need to be mapped to user space. It'd be quite nice to be able to share higher order allocations even if they couldn't be mapped to user space as such. Using 2 MiB pages would probably solve Ricardo's issue, but used alone they'd waste lots of memory for small buffers. If small pages (in Ricardo's case) were used when 2 MiB pages would be too big, e.g. 1 MiB buffer would already have 256 pages in it. Perhaps it'd be useful to specify whether large pages should be always preferred over smaller ones. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
