Thanks for getting back to me. My team found a way to work around the issue directly in the gpu driver. With some modifications, the majority of the graphics memory allocations could be moved into a 32-bit cma region outside of lowmem. > The quickest solution for you is to rebuild the kernel with a 2:2 memory > split so that ZONE_DMA is bigger (around 1.7GB). This was one of the first I things tried. I saw unexplained userspace crashes. Other team members had issues booting. Even if it was working with our config, we have some applications that wouldn't like the 2G VSS limit. So rather than debug the 2:2 split, we moved on to trying to analyze and optimize lowmem usage. I will keep the recommendation in mind in case there's any trouble in testing our CMA solution. > An alternative might be to invent a new zone, something like ZONE_HIGHMEM32, > which is highmem but still within 32-bit physical address space. However, it > will take some effort to justify and upstream it. I had started doing just that when another team member found our current solution. I still think this approach would be workable and has an advantage over 2:2 split in terms of impact on userspace VSS limit. But there's no clean way to add a new zone without impacting a lot of core, arch-generic code. For that reason, I agree it would be difficult to upstream such a change. - Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
