On Mon, Aug 31, 2020 at 09:55:17AM +0100, Mel Gorman wrote:
> On Mon, Aug 31, 2020 at 04:23:06PM +0800, Feng Tang wrote:
> > On Mon, Aug 31, 2020 at 08:56:11AM +0100, Mel Gorman wrote:
> > > On Mon, Aug 31, 2020 at 10:16:38AM +0800, Feng Tang wrote:
> > > > > So why don't you define both variables
On Mon, Aug 31, 2020 at 04:23:06PM +0800, Feng Tang wrote:
> On Mon, Aug 31, 2020 at 08:56:11AM +0100, Mel Gorman wrote:
> > On Mon, Aug 31, 2020 at 10:16:38AM +0800, Feng Tang wrote:
> > > > So why don't you define both variables with DEFINE_PER_CPU_ALIGNED and
> > > > check if all your bad
On Mon, Aug 31, 2020 at 08:56:11AM +0100, Mel Gorman wrote:
> On Mon, Aug 31, 2020 at 10:16:38AM +0800, Feng Tang wrote:
> > > So why don't you define both variables with DEFINE_PER_CPU_ALIGNED and
> > > check if all your bad measurements go away this way?
> >
> > For 'arch_freq_scale', there are
On Mon, Aug 31, 2020 at 10:16:38AM +0800, Feng Tang wrote:
> > So why don't you define both variables with DEFINE_PER_CPU_ALIGNED and
> > check if all your bad measurements go away this way?
>
> For 'arch_freq_scale', there are other percpu variables in the same
> smpboot.c: 'arch_prev_aperf' and
On Fri, Aug 28, 2020 at 07:48:39PM +0200, Borislav Petkov wrote:
> On Tue, Aug 25, 2020 at 02:23:05PM +0800, Feng Tang wrote:
> > Also one good news is, we seem to identify the 2 key percpu variables
> > out of the list mentioned in previous email:
> > 'arch_freq_scale'
> > 'tsc_adjust'
On Tue, Aug 25, 2020 at 02:23:05PM +0800, Feng Tang wrote:
> Also one good news is, we seem to identify the 2 key percpu variables
> out of the list mentioned in previous email:
> 'arch_freq_scale'
> 'tsc_adjust'
>
> These 2 variables are accessed in 2 hot call stacks (for this 288
On Wed, Aug 26, 2020 at 12:44:37AM +0800, Luck, Tony wrote:
> > These 2 variables are accessed in 2 hot call stacks (for this 288 CPU
> > Xeon Phi platform):
>
> This might be the key element of "weirdness" for this system. It
> has 288 CPUs ... cache alignment problems are often not too bad
> on
> These 2 variables are accessed in 2 hot call stacks (for this 288 CPU
> Xeon Phi platform):
This might be the key element of "weirdness" for this system. It
has 288 CPUs ... cache alignment problems are often not too bad
on "small" systems. The as you scale up to bigger machines you
suddenly
On Mon, Aug 24, 2020 at 05:56:53PM +0100, Mel Gorman wrote:
> On Mon, Aug 24, 2020 at 06:12:38PM +0200, Borislav Petkov wrote:
> >
> > > :) Right, this is what I'm doing right now. Some test job is queued on
> > > the test box, and it may needs some iterations of new patch. Hopefully we
> > >
On Mon, Aug 24, 2020 at 06:12:38PM +0200, Borislav Petkov wrote:
> > -DEFINE_PER_CPU(struct mce, injectm);
> > +DEFINE_PER_CPU_ALIGNED(struct mce, injectm);
> > EXPORT_PER_CPU_SYMBOL_GPL(injectm);
>
> I don't think this is the right fix.
Agreed :) This is a debug patch, what we want is to root
On Mon, Aug 24, 2020 at 06:12:38PM +0200, Borislav Petkov wrote:
>
> > :) Right, this is what I'm doing right now. Some test job is queued on
> > the test box, and it may needs some iterations of new patch. Hopefully we
> > can isolate some specific variable given some luck.
>
> ... yes,
On Mon, Aug 24, 2020 at 11:33:00PM +0800, Feng Tang wrote:
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 43b1519..2c020ef 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -95,7 +95,7 @@ struct mca_config mca_cfg
On Mon, Aug 24, 2020 at 11:38:53PM +0800, Luck, Tony wrote:
> > Yes, that's what we suspected. And I just did another try to force the
> > percpu mce structure aligned. And the regression seems to be gone (reduced
> > from 14.1% to 2%), which further proved it.
>
> I wonder whether it would be
> Yes, that's what we suspected. And I just did another try to force the
> percpu mce structure aligned. And the regression seems to be gone (reduced
> from 14.1% to 2%), which further proved it.
I wonder whether it would be useful for bisection of performance issues
for you to change the global
On Mon, Aug 24, 2020 at 05:14:25PM +0200, Borislav Petkov wrote:
> On Fri, Aug 21, 2020 at 10:02:59AM +0800, Feng Tang wrote:
> > 1de08dccd383 x86/mce: Add a struct mce.kflags field
> > 9554bfe403bd x86/mce: Convert the CEC to use the MCE notifier
> >
> > And strange thing is after using gcc9
On Fri, Aug 21, 2020 at 10:02:59AM +0800, Feng Tang wrote:
> 1de08dccd383 x86/mce: Add a struct mce.kflags field
> 9554bfe403bd x86/mce: Convert the CEC to use the MCE notifier
>
> And strange thing is after using gcc9 and debian10 rootfs, with same commits
> the regression turns to a
On Wed, Aug 19, 2020 at 10:23:11AM +0800, Luck, Tony wrote:
> 00019260 D pqr_state
>
> Do you have /sys/fs/resctrl mounted? This variable is read on every context
> switch.
> If your benchmark does a lot of context switching and this now shares a cache
> line
> with something
On Wed, Aug 19, 2020 at 10:23:11AM +0800, Luck, Tony wrote:
> 00019260 D pqr_state
>
> Do you have /sys/fs/resctrl mounted? This variable is read on every context
> switch.
> If your benchmark does a lot of context switching and this now shares a cache
> line
> with something
00019260 D pqr_state
Do you have /sys/fs/resctrl mounted? This variable is read on every context
switch.
If your benchmark does a lot of context switching and this now shares a cache
line
with something different (especially something that is sometimes modified from
another
On Tue, Aug 18, 2020 at 01:06:54PM -0700, Luck, Tony wrote:
> On Tue, Aug 18, 2020 at 04:29:43PM +0800, Feng Tang wrote:
> > Hi Borislav,
> >
> > On Sat, Apr 25, 2020 at 03:01:36PM +0200, Borislav Petkov wrote:
> > > On Sat, Apr 25, 2020 at 07:44:14PM +0800, kernel test robot wrote:
> > > >
On Tue, Aug 18, 2020 at 04:29:43PM +0800, Feng Tang wrote:
> Hi Borislav,
>
> On Sat, Apr 25, 2020 at 03:01:36PM +0200, Borislav Petkov wrote:
> > On Sat, Apr 25, 2020 at 07:44:14PM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -14.1% regression of
Hi Borislav,
On Sat, Apr 25, 2020 at 03:01:36PM +0200, Borislav Petkov wrote:
> On Sat, Apr 25, 2020 at 07:44:14PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed a -14.1% regression of will-it-scale.per_process_ops due to
> > commit:
> >
> >
> > commit:
22 matches
Mail list logo
