> 
> In current patch I simply put newly allocated block to the tail of a free 
> list,
> thus reduce fragmentation, giving a chance to resolve allocation request using
> older blocks with possible holes left.

It's great.
I think this might be helpful for fragmentation by mix of long-time, short-time 
mappings.
I do thank you for your work.

> 
> Signed-off-by: Roman Pen <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Eric Dumazet <[email protected]>
> Acked-by: Joonsoo Kim <[email protected]>
> Cc: David Rientjes <[email protected]>
> Cc: WANG Chao <[email protected]>
> Cc: Fabian Frederick <[email protected]>
> Cc: Christoph Lameter <[email protected]>
> Cc: Gioh Kim <[email protected]>
> Cc: Rob Jones <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
>   mm/vmalloc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 39c3388..db6bffb 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -837,7 +837,7 @@ static struct vmap_block *new_vmap_block(gfp_t gfp_mask)
>   
>       vbq = &get_cpu_var(vmap_block_queue);
>       spin_lock(&vbq->lock);
> -     list_add_rcu(&vb->free_list, &vbq->free);
> +     list_add_tail_rcu(&vb->free_list, &vbq->free);
>       spin_unlock(&vbq->lock);
>       put_cpu_var(vmap_block_queue);
>   
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to