linux-kernel - Re: 2.6.22 -mm merge plans -- vm bugfixes

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]

Message-ID: <4639DBEC.2020401@yahoo.com.au>
Date:	Thu, 03 May 2007 22:56:12 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrea Arcangeli <andrea@...e.de>
Subject: Re: 2.6.22 -mm merge plans -- vm bugfixes

Christoph Hellwig wrote:
> On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
> 
>>The attached patch gets performance up a bit by avoiding some
>>barriers and some cachelines:
>>
>>G5
>>         pagefault   fork          exec
>>2.6.21   1.49-1.51   164.6-170.8   741.8-760.3
>>+patch   1.71-1.73   175.2-180.8   780.5-794.2
>>+patch2  1.61-1.63   169.8-175.0   748.6-757.0
>>
>>So that brings the fork/exec hits down to much less than 5%, and
>>would likely speed up other things that lock the page, like write
>>or page reclaim.
> 
> 
> Is that every fork/exec or just under certain cicumstances?
> A 5% regression on every fork/exec is not acceptable.

Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
specific lock/unlock bitops, I hope it should reduce that further.

The overhead that is there should just be coming from the extra
overhead in the file backed fault handler. For noop fork/execs,
I think that tends to be more pronounced, it is hard to see any
difference on any non-micro benchmark.

The other thing is that I think there could be some cache effects
happening -- for example the exec numbers on the 2nd line are
disproportionately large.

It definitely isn't a good thing to drop performance anywhere
though, so I'll keep looking for improvements.

-- 
SUSE Labs, Novell Inc.
-
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/