From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28 Date: Wed, 17 Sep 2008 14:49:43 +0200 Message-ID: <20080917124943.GA7738@elte.hu> References: <1221306287.5213.111.camel@marge.simson.net> <48CD1D25.9080301@linux-foundation.org> <1221421907.4597.24.camel@marge.simson.net> <1221475440.4784.39.camel@marge.simson.net> <1221568105.5020.17.camel@marge.simson.net> <1221626391.5043.13.camel@marge.simson.net> <1221627676.5125.3.camel@marge.simson.net> <20080917104044.GC18764@elte.hu> <1221651701.5102.17.camel@marge.simson.net> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <1221651701.5102.17.camel-YqMYhexLQo1vAv1Ojkdn7Q@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Mike Galbraith Cc: Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Christoph Lameter , "Rafael J. Wysocki" , LKML , kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org * Mike Galbraith wrote: > > It looks like a potentially bogus bisection result, but _maybe_ it > > has relevance: changes the size of "struct security_operations", > > which could have alignment and layout effects on all sorts of kernel > > variables, kmalloc sizes, etc. > > This may well be a mythical creature infestation for all I know ;-), > but it's address is somewhere in the 2069f45..847106f block, 316 > commits, none of which look like they should be the least bit > interesting to netperf. I reverted this particular commit in 27.git, > got the expected result. Looks like I'll keep poking at it, can't > seem to resist. Grr. are you sure it's 2069f45..847106f? Filtering out the likely-uninteresting commits: git log --pretty=format:"%h: %s" 2069f45..847106f | grep -viE \ 'block|alsa|pcmcia|sound|Merge|iosched|blk|DAC960|scsi|s390|paride|pktcdvd|filter|cdrom|drm' gives us: 7daf705: Start using the new '%pS' infrastructure to print symbols 6f0f0fd: security: remove register_security hook 93cbace: security: remove dummy module fix 5915eb5: security: remove dummy module b478a9f: security: remove unused sb_get_mnt_opts hook 32502b8: splice: fix generic_file_splice_read() race with page invalidation 8b3d356: ramfs: enable splice write a144ff0: xen: Avoid allocations causing swap activity on the resume path which really only leaves that security commit your bisection fingered. Which _slightly_ raises its likelyhood of being implicated. Structure size changes can move two formerly far-apart netperf-relevant symbols on the same cacheline, which can start cache ping-pong-ing badly. It wouldnt be the first such incident - alignment changes impacting macro benchmarks. (and it's hard to find it as the thing that changes alignment/size/sharedness might be something totally unrelated) It's still a bit too early to say this for sure though ... Ingo