On Tue, 20 Sep 2016 14:02:26 +0800 zijun_hu <zijun...@zoho.com> wrote:
> From: zijun_hu <zijun...@htc.com> > > correct a few logic error in __insert_vmap_area() since the else if > condition is always true and meaningless > > avoid endless loop under [un]mapping improper ranges whose boundary > are not aligned to page > > correct lazy_max_pages() return value if the number of online cpus > is power of 2 > > improve performance for pcpu_get_vm_areas() via optimizing vmap_areas > overlay checking algorithm and finding near vmap_areas by list_head > other than rbtree > > simplify /proc/vmallocinfo implementation via seq_file helpers > for list_head > > Signed-off-by: zijun_hu <zijun...@htc.com> > Signed-off-by: zijun_hu <zijun...@zoho.com> Could you submit each of these changes as a separate patch? Would you consider using capitalisation and punctuation in the changelog? Did you measure any performance improvements, or do you have a workload where vmalloc shows up in profiles? > @@ -108,6 +108,9 @@ static void vunmap_page_range(unsigned long addr, > unsigned long end) > unsigned long next; > > BUG_ON(addr >= end); > + WARN_ON(!PAGE_ALIGNED(addr | end)); I prefer to avoid mixing bitwise and arithmetic operations unless it's necessary. Gcc should be able to optimise WARN_ON(!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(end)) > + addr = round_down(addr, PAGE_SIZE); I don't know if it's really necessary to relax the API like this for internal vmalloc.c functions. If garbage is detected here, it's likely due to a bug, and I'm not sure that rounding it would solve the problem. For API functions perhaps it's reasonable -- in such cases you should consider using WARN_ON_ONCE() or similar. Thanks, Nick
