lkml.org 
[lkml]   [2017]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1] mm/vmalloc: add a node corresponding to cached_hole_size
On Fri 21-07-17 04:39:48, Matthew Wilcox wrote:
> On Fri, Jul 21, 2017 at 06:01:41PM +0800, Zhaoyang Huang wrote:
> > we just record the cached_hole_size now, which will be used when
> > the criteria meet both of 'free_vmap_cache == NULL' and 'size <
> > cached_hole_size'. However, under above scenario, the search will
> > start from the rb_root and then find the node which just in front
> > of the cached hole.
> >
> > free_vmap_cache miss:
> > vmap_area_root
> > / \
> > _next U
> > / (T1)
> > cached_hole_node
> > /
> > ... (T2)
> > /
> > first
> >
> > vmap_area_list->first->......->cached_hole_node->cached_hole_node.list.next
> > |-------(T3)-------| | <<< cached_hole_size >>> |
> >
> > vmap_area_list->......->cached_hole_node->cached_hole_node.list.next
> > | <<< cached_hole_size >>> |
> >
> > The time cost to search the node now is T = T1 + T2 + T3.
> > The commit add a cached_hole_node here to record the one just in front of
> > the cached_hole_size, which can help to avoid walking the rb tree and
> > the list and make the T = 0;
>
> Yes, but does this matter in practice? Are there any workloads where
> this makes a difference? If so, how much?

I have already asked this and didn't get any response. There were other
versions of a similar patch without a good clarification...

Zhaoyang Huang, please try to formulate the problem you are fixing and
why. While it is clear that you add _an_ optimization it is not really
clear why we need it and whether it might adversely affect existing
workloads. I would rather not touch this code unless there is a strong
justification for it.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-07-21 16:48    [W:0.050 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site