Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 11 Jan 2024 20:02:16 +1100 | From | Dave Chinner <> | Subject | Re: [PATCH v3 07/11] mm: vmalloc: Offload free_vmap_area_lock lock |
| |
On Tue, Jan 02, 2024 at 07:46:29PM +0100, Uladzislau Rezki (Sony) wrote: > Concurrent access to a global vmap space is a bottle-neck. > We can simulate a high contention by running a vmalloc test > suite. > > To address it, introduce an effective vmap node logic. Each > node behaves as independent entity. When a node is accessed > it serves a request directly(if possible) from its pool. > > This model has a size based pool for requests, i.e. pools are > serialized and populated based on object size and real demand. > A maximum object size that pool can handle is set to 256 pages. > > This technique reduces a pressure on the global vmap lock. > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Why not use a llist for this? That gets rid of the need for a new pool_lock altogether...
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| ![\](/images/icornerr.gif) |