On Thu, Aug 26, 2010 at 11:49 AM, Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > On Thu, Aug 26, 2010 at 8:31 AM, Jonathan Corbet <corbet@xxxxxxx> wrote: >> On Wed, 25 Aug 2010 15:58:14 -0700 >> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> >>> > If you want guarantees you can free stuff, why not add constraints to >>> > the page allocation type and only allow MIGRATE_MOVABLE pages inside a >>> > certain region, those pages are easily freed/moved aside to satisfy >>> > large contiguous allocations. >>> >>> That would be good. Although I expect that the allocation would need >>> to be 100% rock-solid reliable, otherwise the end user has a >>> non-functioning device. Could generic core VM provide the required level >>> of service? >> >> The original OLPC has a camera controller which requires three contiguous, >> image-sized buffers in memory. That system is a little memory constrained >> (OK, it's desperately short of memory), so, in the past, the chances of >> being able to allocate those buffers anytime some kid decides to start >> taking pictures was poor. Thus, cafe_ccic.c has an option to snag the >> memory at initialization time and never let go even if you threaten its >> family. Hell hath no fury like a little kid whose new toy^W educational >> tool stops taking pictures. >> >> That, of course, is not a hugely efficient use of memory on a >> memory-constrained system. If the VM could reliably satisfy those >> allocation requestss, life would be wonderful. Seems difficult. But it >> would be a nicer solution than CMA, which, to a great extent, is really >> just a standardized mechanism for grabbing memory and never letting go. >> >>> It would help (a lot) if we could get more attention and buyin and >>> fedback from the potential clients of this code. rmk's feedback is >>> valuable. Have we heard from the linux-media people? What other >>> subsystems might use it? ieee1394 perhaps? Please help identify >>> specific subsystems and I can perhaps help to wake people up. >> >> If this code had been present when I did the Cafe driver, I would have used >> it. I think it could be made useful to a number of low-end camera drivers >> if the videobuf layer were made to talk to it in a way which Just Works. >> >> With a bit of tweaking, I think it could be made useful in other >> situations: the viafb driver, for example, really needs an allocator for >> framebuffer memory and it seems silly to create one from scratch. Of >> course, there might be other possible solutions, like adding a "zones" >> concept to LMB^W memblock. >> >> The problem which is being addressed here is real. >> >> That said, the complexity of the solution still bugs me a bit, and the core >> idea is still to take big chunks of memory out of service for specific >> needs. It would be far better if the VM could just provide big chunks on >> demand. Perhaps compaction and the pressures of making transparent huge >> pages work will get us there, but I'm not sure we're there yet. >> >> jon > > I agree. compaction and movable zone will be one of good solutions. > > If some driver needs big contiguous chunk to work, it should make sure > to be allowable to have memory size for it before going. To make sure > it, we have to consider compaction of ZONE_MOVABLE zone. But one of > problems is anonymous page which can be has a role of pinned page in > non-swapsystem. Even most of embedded system has no swap. > But it's not hard to solve it. > > We needs Mel's opinion, too. I elaborates my statement for preventing confusing due to using _pinned page_. I means that anon pages isn't not a fragment problem but space problem for the devices. It would be better to move the pages into !ZONE_MOVABLE zone. > > -- > Kind regards, > Minchan Kim > -- Kind regards, Minchan Kim -- 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
