Hi Sakarius I think the whole point of the videobuf2 is sharing pages with the user space, so until vm_insert_page does not support high order pages we should split them. Unfortunately the mm is completely out of my topic, so I don't think that I could be very useful there. With my patch, in the worst case scenario, the image is split in as many blocks as today, but in a normal setup the ammount of blocks is 1 or two blocks in total!. Best regards. On Wed, Jul 31, 2013 at 8:37 AM, Sakari Ailus <sakari.ailus@xxxxxx> wrote: > 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 -- Ricardo Ribalda -- 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
