On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote: > During finding a suitable hole in the vmap_area_list > there is an explicit rescheduling check for latency reduction. > We do it, since there are workloads which are sensitive for > long (more than 1 millisecond) preemption off scenario.
I understand your problem, but this is a horrid solution. If it takes us a millisecond to find a suitable chunk of free address space, something is terribly wrong. On a 3GHz CPU, that's 3 million clock ticks! I think our real problem is that we have no data structure that stores free VA space. We have the vmap_area which stores allocated space, but no data structure to store free space. My initial proposal would be to reuse the vmap_area structure and store the freed ones in a second rb_tree sorted by the size (ie va_end - va_start). When freeing, we might need to merge forwards and backwards. Allocating would be a matter of finding an area preferably of the exact right size; otherwise split a larger free area into a free area and an allocated area (there's a lot of literature on how exactly to choose which larger area to split; memory allocators are pretty well-studied).
