On Thu, Jan 11, 2024 at 08:02:16PM +1100, Dave Chinner wrote: > 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@xxxxxxxxx> > > Why not use a llist for this? That gets rid of the need for a > new pool_lock altogether... > Initially i used the llist. I have changed it because i keep track of objects per a pool to decay it later. I do not find these locks as contented one therefore i did not think much. Anyway, i will have a look at this to see if llist is easy to go with or not. If so i will send out a separate patch. Thanks! -- Uladzislau Rezki
