ad.
Please feel free to help test and add your Tested-by: tag in the patch
thread if possible.
>
>
>
> From: Rahul Gopakumar
> Sent: 24 November 2020 8:33 PM
> To: b...@redhat.com
> Cc: linux...@kvack.org ; linux-kernel@vger.kernel.org
> ; a...@linux-foundation.org
On 11/20/20 at 03:11am, Rahul Gopakumar wrote:
> Hi Baoquan,
>
> To which commit should we apply the draft patch. We tried applying
> the patch to the commit 3e4fb4346c781068610d03c12b16c0cfb0fd24a3
> (the one we used for applying the previous patch) but it fails.
I tested on 5.10-rc3+. You can a
On 11/03/20 at 12:34pm, Rahul Gopakumar wrote:
> >> So, you mean with the draft patch applied, the initial performance
> regression goes away, just many page corruption errors with call trace
> are seen, right?
>
> Yes, that's right.
>
> >> And the performance regression is about 2sec delay in
>
On 11/03/20 at 12:34pm, Rahul Gopakumar wrote:
> >> So, you mean with the draft patch applied, the initial performance
> regression goes away, just many page corruption errors with call trace
> are seen, right?
>
> Yes, that's right.
>
> >> And the performance regression is about 2sec delay in
>
tal system with more than 1T memory, didn't see the page
corruption call trace, need reproduce and have a look.
>
>
>
> From: Rahul Gopakumar
> Sent: 22 October 2020 10:51 PM
> To: b...@redhat.com
> Cc: linux...@kva
Hi Rahul,
On 10/20/20 at 03:26pm, Rahul Gopakumar wrote:
> >> Here, do you mean it even cost more time with the patch applied?
>
> Yes, we ran it multiple times and it looks like there is a
> very minor increase with the patch.
>
..
> On 10/20/20 at 01:45pm, Rahul Gopakumar wrote:
> > Hi B
> - memmap_init_zone(size, nid, zone, start_pfn,
> + memmap_init_zone(size, nid, zone, start_pfn,
> range_end_pfn,
> MEMINIT_EARLY, NULL);
> }
> }
>
>
> -
Hi Rahul,
On 10/12/20 at 05:21pm, Rahul Gopakumar wrote:
> Hi Baoquan,
>
> Attached collected dmesg logs for with and without
> commit after adding memblock=debug to kernel cmdline.
Can you test below draft patch and see if it works for you?
>From a2ea6caef3c73ad9efb2dd2b48039065fe430bb2 Mon S
On 10/12/20 at 05:21pm, Rahul Gopakumar wrote:
> Hi Baoquan,
>
> Attached collected dmesg logs for with and without
> commit after adding memblock=debug to kernel cmdline.
Thanks, I have got the root cause, will make a patch for your testing
soon.
On 10/09/20 at 01:15pm, Rahul Gopakumar wrote:
> As part of VMware's performance regression testing for Linux Kernel
> upstream releases, we identified boot time increase when comparing
> Linux 5.8 kernel against Linux 5.7 kernel. Increase in boot time is
> noticeable on VM with a **large amount of
Hi Junichi,
On 03/26/19 at 02:57pm, Borislav Petkov wrote:
> On Mon, Mar 25, 2019 at 11:10:01PM +, Junichi Nomura wrote:
> > efi_get_rsdp_addr() and kexec_get_rsdp_addr() could be implemented
> > like this (sorry about the pseudo code):
>
> This doesn't look like what I suggested:
>
> > So e
On 07/31/17 at 07:20pm, Dou Liyang wrote:
> Hi Baoquan,
>
> At 07/27/2017 02:08 PM, b...@redhat.com wrote:
> > On 07/26/17 at 08:19pm, Dou Liyang wrote:
> > > Hi Baoquan,
> [...]
> > >
> > > I am looking for Thinkpad x121e (AMD E-450 APU) to test. I h
init/main.c
> +++ b/init/main.c
> @@ -655,12 +655,12 @@ asmlinkage __visible void __init start_kernel(void)
> kmemleak_init();
> setup_per_cpu_pageset();
> numa_policy_init();
> - acpi_early_init();
> if (late_time_init)
> late_time_init();
om]
> > > Sent: Friday, July 14, 2017 1:53 PM
> > > To: x...@kernel.org; linux-kernel@vger.kernel.org
> > > Cc: t...@linutronix.de; mi...@kernel.org; h...@zytor.com;
> > > ebied...@xmission.com; b...@redhat.com;
> > > pet...@infradead.org; izumi.t...@jp.
On 08/02/16 at 07:45am, Wei, Jiangang wrote:
> Hi Eric,
>
> Thanks for your reply firstly.
>
> On Mon, 2016-08-01 at 12:09 -0500, Eric W. Biederman wrote:
> > "Wei, Jiangang" writes:
> >
> > > Ping ...
> > > May I ask for some community attention to this series?
> > > I purpose is fixing the d
On 07/20/16 at 08:32am, Thomas Gleixner wrote:
> On Wed, 20 Jul 2016, b...@redhat.com wrote:
> > On 07/20/16 at 03:54am, Wei, Jiangang wrote:
> >
> > > In fact, Eric and Ingo suggested that "it should be fixed in the bootup
> > > path of the dump kernel, no
On 07/20/16 at 03:54am, Wei, Jiangang wrote:
> Hi Baoquan He,
>
> Well, Indeed there‘s a relationship between the dump-capture hangs in
> calibrate_delay_converge() and the interrupt mode.
>
> but there‘s no essential difference between your patches and mine that
> calls disable_IO_APIC() again.
Hi Jiangang,
On 07/20/16 at 03:54am, Wei, Jiangang wrote:
> Hi Baoquan He,
>
> Well, Indeed there‘s a relationship between the dump-capture hangs in
> calibrate_delay_converge() and the interrupt mode.
>
> but there‘s no essential difference between your patches and mine that
> calls disable_IO_
Hi Junichi,
A little earlier Peter Hurley has posted a patch to fix this problem.
https://lkml.org/lkml/2015/11/27/546
It may be found firstly on arm by Pratyush Anand .
I found it too this week on Fedora 23.
Anyway, it's great problem has been fixed very quickly. Just reply to
let you know this
19 matches
Mail list logo
