linux-kernel - Re: 2.6.38 sbrk regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Apr 2011 14:49:14 +0300
From:	raz ben yehuda <raziebe@...il.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, riel@...hat.com,
	kosaki.motohiro@...fujitsu.com, akpm@...ux-foundation.org,
	Mel Gorman <mel@....ul.ie>
Subject: Re: 2.6.38 sbrk regression

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).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/