Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

+Tobin C. Harding On Wed, May 15, 2019 at 5:24 PM Uladzislau Rezki wrote: > > Hello, Andrew. > > > An earlier version of this patch was accused of crashing the kernel: > > > > https://lists.01.org/pipermail/lkp/2019-April/010004.html > > > > does the v4 series address this? > I tried before to

Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

Hello, Andrew. > An earlier version of this patch was accused of crashing the kernel: > > https://lists.01.org/pipermail/lkp/2019-April/010004.html > > does the v4 series address this? I tried before to narrow down that crash but i did not succeed, so i have never seen that before on my test

Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

An earlier version of this patch was accused of crashing the kernel: https://lists.01.org/pipermail/lkp/2019-April/010004.html does the v4 series address this?

Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

Hello, Roman. > > Reviewed-by: Roman Gushchin > > Thanks! I appreciate your effort in reviewing to make it better. Thank you! -- Uladzislau Rezki

Re: [PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

On Sat, Apr 06, 2019 at 08:35:06PM +0200, Uladzislau Rezki (Sony) wrote: > Currently an allocation of the new vmap area is done over busy > list iteration(complexity O(n)) until a suitable hole is found > between two busy areas. Therefore each new allocation causes > the list being grown. Due to

[PATCH v4 1/3] mm/vmap: keep track of free blocks for vmap allocation

Currently an allocation of the new vmap area is done over busy list iteration(complexity O(n)) until a suitable hole is found between two busy areas. Therefore each new allocation causes the list being grown. Due to over fragmented list and different permissive parameters an allocation can take a