Re: 2.6.38 sbrk regression

[raz ben yehuda <raziebe@gmail.com>]

Hey Andrea
Me again. I managed to ftrace ( function graph ) the two kernels. I used
2.6.37 and 2.6.39-rc3. The bellow is example for sys_brk calls traces
from each kernel. As you can see, there is no "single smoking gun"
here. 

The vm functions durations increased as a whole.
I repeated the tests from sha1 4e9f64c42d0ba5eb0c78569435ada4c224332ce4
compared to sha1 152c9ccb75548c027fa3103efa4fa4e19a345449  and it is
consistent. ~13% performance decrease.

Can you see any relation to thp that might causes this degradation ?

thank you
raz

2.6.39-rc3

 0)       .       |  sys_brk() {
 0)   0.205 us    |    down_write();
 0)   0.256 us    |    find_vma();
 0)               |    do_brk() {
 0)   0.549 us    |      cap_file_mmap();
 0)               |      get_unmapped_area() {
 0)   0.130 us    |        arch_get_unmapped_area_topdown();
 0)   1.112 us    |      }
 0)               |      cap_vm_enough_memory() {
 0)   0.163 us    |        __vm_enough_memory();
 0)   1.408 us    |      }
 0)               |      vma_merge() {
 0)   0.313 us    |        vma_adjust();
 0)   2.315 us    |      }
 0)   9.692 us    |    }
 0)   0.168 us    |    up_write();
 0) + 14.473 us   |  }

2.6.37
 0)               |  sys_brk() {
 0)   0.261 us    |    down_write();
 0)   0.416 us    |    find_vma();
 0)               |    do_brk() {
 0)   0.411 us    |      cap_file_mmap();
 0)               |      get_unmapped_area() {
 0)   0.443 us    |        arch_get_unmapped_area_topdown();
 0)   0.982 us    |      }
 0)               |      cap_vm_enough_memory() {
 0)   0.481 us    |        __vm_enough_memory();
 0)   1.145 us    |      }
 0)               |      vma_merge() {
 0)   0.459 us    |        vma_adjust();
 0)   1.004 us    |      }
 0)   5.423 us    |    }
 0)   0.273 us    |    up_write();
 0)   8.020 us    |  }




On Wed, 2011-04-13 at 19:21 +0200, Andrea Arcangeli wrote:
> On Wed, Apr 13, 2011 at 05:06:19PM +0300, raz ben yehuda wrote:
> > ok, managed to build 38-rc3 ( keep forgetting make mrproper ).
> > problem is still there:
> 
> Oops I thought it was typo on your prev email so I didn't answer
> assuming you would test 39-rc like I suggested in my prev email, I
> really meant 2.6.39-rc3.
> 
> The fix I refer to is d527caf22e48480b102c7c6ee5b9ba12170148f7 and
> it's included in >= 2.6.39-rc1. 38-rc3 has THP but not this
> changeset. We tried to push it for 38 final but it was a bit late so
> it got merged immediately in 39-rc1 to stay on the safe side (it's
> only a performance issue and the other longstanding irq/sched latency
> issues in compaction that got fixed in 39-rc1 where actually more
> relevant than the compaction-kswapd removal).