Contiguous memory allocation for drivers

Posted Jul 22, 2010 9:16 UTC (Thu) by mjthayer (guest, #39183)
Parent article: Contiguous memory allocation for drivers

Since most memory allocations don't care about where they are in physical memory, wouldn't it be possible to have contiguous memory reclaiming code which would move bits of don't-have-to-be-contiguous memory about until it could defragment enough for a contiguous allocation? Of course, that would be expensive, but I could see it having its place as an emergency or guarantee measure alongside attempts to ensure that there is enough contiguous memory for "normal" use. It might also be more effective if it were done gradually in the background when it looked like contiguous memory might become tight in the forseeable future, not to mention if the rest of the memory subsystem were adjusted to take it into account.

to post comments

Contiguous memory allocation for drivers

Posted Jul 22, 2010 11:09 UTC (Thu) by SimonO (guest, #56318) [Link]

Exactly, what's the point of memory management if it doesn't manage all possible needs? ;-)

I'd imagine a configuration parameter telling the memory management to start de-fragmenting memory as soon as a certain threshold is crossed, so that at any time when a camera-app or some other driver requests a chunk of contiguous memory, the request can quickly be satisfied. If the total amount of memory is insufficient for the normal workload and the newly started program with a need for contiguous memory isn't feasible, something can be done about it at that time.

I think that insufficient memory is a concept that users can understand, while insufficient contiguous memory is a lot harder to grasp. It's the job of the kernel to solve it for the user.

Cheers

Simon

Shifting memory around

Posted Jul 22, 2010 13:25 UTC (Thu) by corbet (editor, #1) [Link]

Indeed, that's just what the lumpy reclaim and memory compaction features do. They've helped, but it's still hard to reliably provide physically contiguous buffers in the megabyte size range, especially on smaller systems which don't have a whole lot of memory in the first place.

Contiguous memory allocation for drivers

Posted Jul 22, 2010 13:34 UTC (Thu) by tsr2 (subscriber, #4293) [Link] (2 responses)

I was thinking about something like this, but more along the lines of a "soft reserved area". If we assume that there are classes of memory that can always be discarded then an area can be reserved for contiguous memory allocation, but it will also allow memory to be allocated for pages that can definitely be safely discarded. When a contiguous memory allocation is required, then there is a block of memory available that can be freed quickly at low cost.

The difficulty for me, as someone unfamiliar with the kernel, is whether sufficient such pages would be available and identifiable? I wondered about I/O buffers, but clearly if the file is writeable then the pages could not always be discarded. If the kernel "knows" whether a file has been opened read only or read/write, that might simplify the question. Also there is a risk of a performance hit from having to dump a large number of buffers.

I'm guessing that such a scheme has already been considered by people that know more than I do about the issues and has been deemed impractical?

Contiguous memory allocation for drivers

Posted Jul 22, 2010 13:53 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, the defragmentation code obviously knows which regions can be defragmented: so there could be a memory zone that contains only allocations that defragmentation could move out of the way, plus regions that could be freed without writeout. I don't think this exists yet, though, and memory zones are single contiguous lumps, not a bunch of individually-contiguous regions like CMA produces. So I suppose 'is in a CMA region' would have to be another page flag or something. But we're perennially short of those...

Contiguous memory allocation for drivers

Posted Jul 25, 2010 11:16 UTC (Sun) by mina86 (guest, #68442) [Link]

What you are describing is exactly what I've put as a future work. I believe that centralising contiguous-memory allocation will help implement a scheme where a free area of the CMA regions can be used for buffers, page cache, etc. Obviously, read-only pages would be preferred as they are trivial to discard but even dirty pages could stay in CMA managed regions of memory.

As I've said, this is, however, a future work. Hopefully, we'll get there some day. :)