[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7E82351C108FA840AB1866AC776AEC46401F518D@orsmsx505.amr.corp.intel.com>
Date: Thu, 30 Oct 2008 17:32:21 -0700
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To: "Siddha, Suresh B" <suresh.b.siddha@...el.com>,
Ingo Molnar <mingo@...e.hu>
CC: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
Roland McGrath <roland@...hat.com>,
Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
Yinghai Lu <yinghai@...nel.org>
Subject: RE: cpu2000(both float and int) 13% regression with 2.6.28-rc1
>-----Original Message-----
>From: linux-kernel-owner@...r.kernel.org
>[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Suresh Siddha
>Sent: Tuesday, October 28, 2008 1:27 PM
>To: Ingo Molnar
>Cc: Zhang, Yanmin; LKML; H. Peter Anvin; Siddha, Suresh B;
>Roland McGrath; Hiroshi Shimamoto; Yinghai Lu
>Subject: Re: cpu2000(both float and int) 13% regression with 2.6.28-rc1
>
>On Tue, Oct 28, 2008 at 01:03:27AM -0700, Ingo Molnar wrote:
>>
>> * Zhang, Yanmin <yanmin_zhang@...ux.intel.com> wrote:
>>
>> > Comparing with 2.6.27, cpu2000 (both float and int) has
>about 13% regression
>> > with 2.6.28-rc1 on my new-model x86-64 machine.
>> >
>> > I bisected down to below patch.
>> >
>> > commit 0afe2db21394820d32646a695eccf3fbfe6ab5c7
>> > Merge: d847059... 43603c8...
>> > Author: Ingo Molnar <mingo@...e.hu>
>> > Date: Sat Oct 11 20:23:20 2008 +0200
>> >
>> > Merge branch 'x86/unify-cpu-detect' into
>x86-v28-for-linus-phase4-D
>> >
>> > Conflicts:
>> > arch/x86/kernel/cpu/common.c
>> > arch/x86/kernel/signal_64.c
>> > include/asm-x86/cpufeature.h
>> >
>> >
>> > When I tried to revert it against 2.6.28-rc2, there are
>many conflictions.
>
>Ingo, I will work with Yanmin and report our findings. It is
>interesting to see
>double digit regression on cpu2000 benchmark. My understanding is that
>these benchmarks are not sensitive to signal handling. Also lmbench
>signal handling(lat_sig) has less than 3-4% regression, because of
>added overhead duing signal setup and restore. Context switch
>didn't have
>any noticeable difference, when I measure before.
>
We figured out that this is not related to signals. But to this mismerge here
> +#define X86_FEATURE_AMDC1E (3*32+21) /* AMD C1E detected */
> + #define X86_FEATURE_XTOPOLOGY (3*32+21) /* cpu topology enum extensions */
I had earler sent a patch to fix this.
http://marc.info/?l=linux-kernel&m=122341178202930&w=2
But, somehow I don’t see this patch either in Linus's git or in tip.
ingo, hpa: Can you push that patch along.
Thanks,
Venki
Powered by blists - more mailing lists