[PATCH] sched/fair: Kill the unused sched_shares_window_ns tunable

Galbraith Signed-off-by: Matt Fleming --- include/linux/sched/sysctl.h | 1 - kernel/sched/fair.c | 7 --- kernel/sysctl.c | 7 --- 3 files changed, 15 deletions(-) diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h index 22db1e63707e..44

Re: [PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

gned-off-by: Alex Thorlton <athorl...@sgi.com> > Cc: Mike Travis <tra...@sgi.com> > Cc: Russ Anderson <r...@sgi.com> > Cc: Dimitri Sivanich <sivan...@sgi.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> >

Re: [PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

-off-by: Alex Thorlton > Cc: Mike Travis > Cc: Russ Anderson > Cc: Dimitri Sivanich > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Matt Fleming > Cc: Masahiro Yamada > Cc: x...@kernel.org > --- > arch/x86/platform/uv/

Re: [GIT PULL 0/8] EFI changes for v4.10

On Tue, 18 Oct, at 05:34:36PM, Lukas Wunner wrote: > On Tue, Oct 18, 2016 at 03:33:10PM +0100, Matt Fleming wrote: > > Folks, please queue up the following small changes for v4.10. > > These are all fixes. Did you mean 4.9? Ingo only queued up > the MAINTAINERS patch for

Re: [GIT PULL 0/8] EFI changes for v4.10

On Tue, 18 Oct, at 05:34:36PM, Lukas Wunner wrote: > On Tue, Oct 18, 2016 at 03:33:10PM +0100, Matt Fleming wrote: > > Folks, please queue up the following small changes for v4.10. > > These are all fixes. Did you mean 4.9? Ingo only queued up > the MAINTAINERS patch for

[PATCH 8/8] efi: efivar_ssdt_load: Don't return success on allocation failure

From: Dan Carpenter We should return -ENOMEM here, instead of success. Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables") Signed-off-by: Dan Carpenter Signed-off-by: Ard Biesheuvel ---

[PATCH 3/8] efi/arm*: efi_init() error handling fix

..@arm.com> Cc: Ingo Molnar <mi...@kernel.org> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/arm-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efi/ar

[PATCH 8/8] efi: efivar_ssdt_load: Don't return success on allocation failure

From: Dan Carpenter We should return -ENOMEM here, instead of success. Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables") Signed-off-by: Dan Carpenter Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

[PATCH 3/8] efi/arm*: efi_init() error handling fix

From: Yisheng Xie There's an early memmap leak in efi_init error path, fix it. Signed-off-by: Yisheng Xie Cc: Catalin Marinas Cc: Mark Rutland Cc: Will Deacon Cc: Ingo Molnar Cc: Ard Biesheuvel Signed-off-by: Matt Fleming --- drivers/firmware/efi/arm-init.c | 4 +++- 1 file changed, 3

[PATCH 6/8] efi/efi_test: Use memdup_user() as a cleanup

n Khoronzhuk <ivan.khoronz...@linaro.org> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/test/efi_test.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/firmware/

[PATCH 6/8] efi/efi_test: Use memdup_user() as a cleanup

From: Ivan Hu Fix coccicheck warning which recommends to use memdup_user() This patch fixes below coccicheck warnings: drivers/firmware/efi/test/efi_test.c:269:8-15: WARNING opportunity for memdup_user Signed-off-by: Ivan Hu Cc: Ivan Khoronzhuk Cc: Ard Biesheuvel Signed-off-by: Matt Fleming

[GIT PULL 0/8] EFI changes for v4.10

Folks, please queue up the following small changes for v4.10. Note that there is a patch to MAINTAINERS in this pull request that adds Ard as EFI co-maintainer. It'd probably be a good idea to send that to Linus before v4.10. The following changes since commit

[PATCH 1/8] MAINTAINERS: add myself as EFI maintainer

From: Ard Biesheuvel <ard.biesheu...@linaro.org> At the request of Matt, I am taking up co-maintainership of the EFI subsystem. So add my name to the EFI section in MAINTAINERS, and change the SCM tree reference to point to the new shared Git repo. Cc: Matt Fleming <m...@codebluepr

[PATCH 4/8] efi/efi_test: Fix the uninitialized value datasize

, data); Signed-off-by: Ivan Hu <ivan...@canonical.com> Cc: Ivan Khoronzhuk <ivan.khoronz...@linaro.org> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/test/efi_test.c | 2 +- 1 file changed, 1 insertion

[GIT PULL 0/8] EFI changes for v4.10

Folks, please queue up the following small changes for v4.10. Note that there is a patch to MAINTAINERS in this pull request that adds Ard as EFI co-maintainer. It'd probably be a good idea to send that to Linus before v4.10. The following changes since commit

[PATCH 1/8] MAINTAINERS: add myself as EFI maintainer

From: Ard Biesheuvel At the request of Matt, I am taking up co-maintainership of the EFI subsystem. So add my name to the EFI section in MAINTAINERS, and change the SCM tree reference to point to the new shared Git repo. Cc: Matt Fleming Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon

[PATCH 4/8] efi/efi_test: Fix the uninitialized value datasize

: Ivan Khoronzhuk Cc: Ard Biesheuvel Signed-off-by: Matt Fleming --- drivers/firmware/efi/test/efi_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/test/efi_test.c b/drivers/firmware/efi/test/efi_test.c index ae51268737cc..348efc9cf59f 100644

[PATCH 7/8] efifb: show framebuffer layout as device attributes

From: Peter Jones Userland sometimes needs to know what the framebuffer configuration was when the firmware was running. This enables us to render localized status strings during firmware updates using the data from the ACPI BGRT table and the protocol described at the url

[PATCH 5/8] efi/efi_test: Fix the uninitialized value rv

gt; Cc: Ivan Khoronzhuk <ivan.khoronz...@linaro.org> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/test/efi_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/

[PATCH 2/8] efi: Remove unused including

From: Wei Yongjun <weiyongj...@huawei.com> Remove including that don't need it. Signed-off-by: Wei Yongjun <weiyongj...@huawei.com> Cc: Ivan Khoronzhuk <ivan.khoronz...@linaro.org> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codebl

[PATCH 5/8] efi/efi_test: Fix the uninitialized value rv

-by: Matt Fleming --- drivers/firmware/efi/test/efi_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/test/efi_test.c b/drivers/firmware/efi/test/efi_test.c index 348efc9cf59f..bb26e12b0cfd 100644 --- a/drivers/firmware/efi/test/efi_test.c +++ b/drivers

[PATCH 2/8] efi: Remove unused including

From: Wei Yongjun Remove including that don't need it. Signed-off-by: Wei Yongjun Cc: Ivan Khoronzhuk Cc: Ard Biesheuvel Signed-off-by: Matt Fleming --- drivers/firmware/efi/test/efi_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/firmware/efi/test/efi_test.c b/drivers

[PATCH 7/8] efifb: show framebuffer layout as device attributes

From: Peter Jones Userland sometimes needs to know what the framebuffer configuration was when the firmware was running. This enables us to render localized status strings during firmware updates using the data from the ACPI BGRT table and the protocol described at the url below:

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 18 Oct, at 01:10:17PM, Peter Zijlstra wrote: > > I'm entirely lost as to which patch we're talking about by now ;-) Heh, this one from Vincent, https://lkml.kernel.org/r/20161010173440.ga28...@linaro.org

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 18 Oct, at 01:10:17PM, Peter Zijlstra wrote: > > I'm entirely lost as to which patch we're talking about by now ;-) Heh, this one from Vincent, https://lkml.kernel.org/r/20161010173440.ga28...@linaro.org

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote: > > That's a lot more costly cross-DIE migrations. I think this patch is > along the right lines, but there's something fishy happening on this > box. I wasn't really able to track down why this machine regressed, and the patch

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote: > > That's a lot more costly cross-DIE migrations. I think this patch is > along the right lines, but there's something fishy happening on this > box. I wasn't really able to track down why this machine regressed, and the patch

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 11:39:57AM, Matt Fleming wrote: > On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote: > > > > [...] > > > > Yeah, you're right. But I can't see any significant difference. IMHO, > > it's all in the noise. > > > > (A) Pe

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 11:39:57AM, Matt Fleming wrote: > On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote: > > > > [...] > > > > Yeah, you're right. But I can't see any significant difference. IMHO, > > it's all in the noise. > > > > (A) Pe

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 03:14:47PM, Vincent Guittot wrote: > > > > I see a regression, > > > > baseline: 2.41228 > > patched : 2.64528 (-9.7%) > > Just to be sure; By baseline you mean v4.8 ? Baseline is actually tip/sched/core commit 447976ef4fd0 ("sched/irqtime: Consolidate irqtime flushing

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 03:14:47PM, Vincent Guittot wrote: > > > > I see a regression, > > > > baseline: 2.41228 > > patched : 2.64528 (-9.7%) > > Just to be sure; By baseline you mean v4.8 ? Baseline is actually tip/sched/core commit 447976ef4fd0 ("sched/irqtime: Consolidate irqtime flushing

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote: > > [...] > > Yeah, you're right. But I can't see any significant difference. IMHO, > it's all in the noise. > > (A) Performance counter stats for 'perf bench sched messaging -g 100 -l > 1 -t' > # 20 sender and receiver threads per

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote: > > [...] > > Yeah, you're right. But I can't see any significant difference. IMHO, > it's all in the noise. > > (A) Performance counter stats for 'perf bench sched messaging -g 100 -l > 1 -t' > # 20 sender and receiver threads per

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Mon, 10 Oct, at 06:09:14PM, Wanpeng Li wrote: > 2016-10-10 18:01 GMT+08:00 Matt Fleming <m...@codeblueprint.co.uk>: > > On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote: > >> > >> The difference between this patch and Peterz's is your patch have a > >>

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Mon, 10 Oct, at 06:09:14PM, Wanpeng Li wrote: > 2016-10-10 18:01 GMT+08:00 Matt Fleming : > > On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote: > >> > >> The difference between this patch and Peterz's is your patch have a > >> delta since activate_task()->

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Mon, 10 Oct, at 07:34:40PM, Vincent Guittot wrote: > > Subject: [PATCH] sched: use load_avg for selecting idlest group > > select_busiest_group only compares the runnable_load_avg when looking for > the idlest group. But on fork intensive use case like hackbenchw here task > blocked quickly

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Mon, 10 Oct, at 07:34:40PM, Vincent Guittot wrote: > > Subject: [PATCH] sched: use load_avg for selecting idlest group > > select_busiest_group only compares the runnable_load_avg when looking for > the idlest group. But on fork intensive use case like hackbenchw here task > blocked quickly

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote: > > The difference between this patch and Peterz's is your patch have a > delta since activate_task()->enqueue_task() does do update_rq_clock(), > so why don't have the delta will cause low cpu machines (4 or 8) to > regress against your another

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote: > > The difference between this patch and Peterz's is your patch have a > delta since activate_task()->enqueue_task() does do update_rq_clock(), > so why don't have the delta will cause low cpu machines (4 or 8) to > regress against your another

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 05:00:20AM, Vincent Guittot wrote: > > Matt, > > May be you can try this patch which uses utilization in > find_idlest_group. So even if runnable_load_avg is null, the > utilization should not and another cpu will be chosen > https://patchwork.kernel.org/patch/9306939/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 05:00:20AM, Vincent Guittot wrote: > > Matt, > > May be you can try this patch which uses utilization in > find_idlest_group. So even if runnable_load_avg is null, the > utilization should not and another cpu will be chosen > https://patchwork.kernel.org/patch/9306939/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote: > > ok so i'm a bit confused there > my understand of your explanation above is that now we left a small > amount of load in runnable_load_avg after the dequeue so another cpu > will be chosen. But this explanation seems to be the opposite of

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote: > > ok so i'm a bit confused there > my understand of your explanation above is that now we left a small > amount of load in runnable_load_avg after the dequeue so another cpu > will be chosen. But this explanation seems to be the opposite of

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 8fb4d1942c14..4a2d3ff772f8 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 8fb4d1942c14..4a2d3ff772f8 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/

Re: [PATCH -next v2] arm*/efi: efi_init error handling fix

On Tue, 20 Sep, at 07:39:53PM, Yisheng Xie wrote: > There's an early memmap leak in efi_init error path, fix it. > > Signed-off-by: Yisheng Xie > --- > drivers/firmware/efi/arm-init.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH -next v2] arm*/efi: efi_init error handling fix

On Tue, 20 Sep, at 07:39:53PM, Yisheng Xie wrote: > There's an early memmap leak in efi_init error path, fix it. > > Signed-off-by: Yisheng Xie > --- > drivers/firmware/efi/arm-init.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/arm-init.c

Re: [PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

On Mon, 03 Oct, at 02:49:07PM, Peter Zijlstra wrote: > On Wed, Sep 21, 2016 at 02:38:07PM +0100, Matt Fleming wrote: > > detach_task_cfs_rq() may indirectly call rq_clock() to inform the > > cpufreq code that the rq utilisation has changed. In which case, we > > need t

Re: [PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

On Mon, 03 Oct, at 02:49:07PM, Peter Zijlstra wrote: > On Wed, Sep 21, 2016 at 02:38:07PM +0100, Matt Fleming wrote: > > detach_task_cfs_rq() may indirectly call rq_clock() to inform the > > cpufreq code that the rq utilisation has changed. In which case, we > > need t

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 08:37:31PM, Matt Fleming wrote: > > I'm away on FTO right now. I can test this when I return on Friday. I haven't had chance to review your patch or the other emails in this thread yet, but I ran the patch on my test machine and it also restores performance. I'

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 08:37:31PM, Matt Fleming wrote: > > I'm away on FTO right now. I can test this when I return on Friday. I haven't had chance to review your patch or the other emails in this thread yet, but I ran the patch on my test machine and it also restores performance. I'

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > > Which suggests we do something like the below (not compile tested or > anything, also I ran out of tea again). I'm away on FTO right now. I can test this when I return on Friday. Funnily enough, I now remember that I already sent a fix

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote: > > Which suggests we do something like the below (not compile tested or > anything, also I ran out of tea again). I'm away on FTO right now. I can test this when I return on Friday. Funnily enough, I now remember that I already sent a fix

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 27 Sep, at 02:48:31PM, Dietmar Eggemann wrote: > > I think Matt is talking about the fact that the cfs->runnable_load_avg > value is 0 once the hackbench task is initially dequeued. Yes. > Without this patch the value of se->avg.load_avg (e.g. both times 1002) > is exactly the same

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Tue, 27 Sep, at 02:48:31PM, Dietmar Eggemann wrote: > > I think Matt is talking about the fact that the cfs->runnable_load_avg > value is 0 once the hackbench task is initially dequeued. Yes. > Without this patch the value of se->avg.load_avg (e.g. both times 1002) > is exactly the same

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Fri, 23 Sep, at 04:30:25PM, Vincent Guittot wrote: > > Does it mean that you can see the perf drop that you mention below > because load is decayed to 1002 instead of staying to 1024 ? The performance drop comes from the fact that enqueueing/dequeueing a task with load 1002 during fork()

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On Fri, 23 Sep, at 04:30:25PM, Vincent Guittot wrote: > > Does it mean that you can see the perf drop that you mention below > because load is decayed to 1002 instead of staying to 1024 ? The performance drop comes from the fact that enqueueing/dequeueing a task with load 1002 during fork()

[PATCH] sched/fair: Do not decay new task load on first enqueue

nel.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Yuyang Du <yuyang...@intel.com> Cc: Vincent Guittot <vincent.guit...@linaro.org> Cc: Dietmar Eggemann <dietmar.eggem...@arm.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/fair.c | 2 +-

[PATCH] sched/fair: Do not decay new task load on first enqueue

t Guittot Cc: Dietmar Eggemann Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 8fb4d1942c14..4a2d3ff772f8 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3142,7 +31

Re: EFI co-maintainer

On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote: > > That is great to hear, thanks a lot from me as well. > > Just curious, are there any plans to integrate the new repo into > linux-next? It would be great to have testing as early as possible. Yes, the existing one is also part of

Re: EFI co-maintainer

On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote: > > That is great to hear, thanks a lot from me as well. > > Just curious, are there any plans to integrate the new repo into > linux-next? It would be great to have testing as early as possible. Yes, the existing one is also part of

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote: > > I am not sure how the above call chain is realistic. But adding > WARN_ON() into the scheduler paths is risky in general. It's not clear to me why this should be the case. WARN_ON() calls have existed in the scheduler paths since forever. If

Re: [PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

On Wed, 21 Sep, at 05:58:27PM, Petr Mladek wrote: > > I am not sure how the above call chain is realistic. But adding > WARN_ON() into the scheduler paths is risky in general. It's not clear to me why this should be the case. WARN_ON() calls have existed in the scheduler paths since forever. If

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, 21 Sep, at 04:35:13PM, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc:

Re: [PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

On Wed, 21 Sep, at 04:35:13PM, Ard Biesheuvel wrote: > At the request of Matt, I am taking up co-maintainership of the EFI > subsystem. So add my name to the EFI section in MAINTAINERS, and > change the SCM tree reference to point to the new shared Git repo. > > Cc: Matt Flemin

EFI co-maintainer

Folks, I've asked, and Ard has agreed to step up and help me co-maintain the EFI subsystem. Given that there are now two maintainers, we're moving to a shared git repository on kernel.org, hosted at, git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git Expect a MAINTAINERS patch soon.

EFI co-maintainer

Folks, I've asked, and Ard has agreed to step up and help me co-maintain the EFI subsystem. Given that there are now two maintainers, we're moving to a shared git repository on kernel.org, hosted at, git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git Expect a MAINTAINERS patch soon.

[PATCH v2 4/7] sched: Add wrappers for lockdep_(un)pin_lock()

uct rq_flags *'. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Mel Gorman <mgor...@techsingularity.net> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> -

[PATCH v2 6/7] sched/fair: Push rq lock pin/unpin into idle_balance()

l.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Mel Gorman <mgor...@techsingularity.net> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/fair.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/kern

[PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

y.net> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/fair.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 986c10c25176..ab1cf3866a5b 100644 -

[PATCH v2 4/7] sched: Add wrappers for lockdep_(un)pin_lock()

uct rq_flags *'. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Signed-off-by: Matt Fleming --- kernel/sched/core.c | 80 kernel/sched/deadline.c | 10 +++--- kernel/sched/fair.c | 6 ++-- kernel/sched/idle_tas

[PATCH v2 6/7] sched/fair: Push rq lock pin/unpin into idle_balance()

-by: Matt Fleming --- kernel/sched/fair.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index f0032827fb79..df9a5b16e1df 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3232,7 +3232,7

[PATCH v2 1/7] sched/fair: Update the rq clock before detaching tasks

detach_task_cfs_rq() may indirectly call rq_clock() to inform the cpufreq code that the rq utilisation has changed. In which case, we need to update the rq clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 5

[PATCH v2 5/7] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

Cc: Mel Gorman <mgor...@techsingularity.net> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7950c372fca0..1254629c9f2f 100644 --- a/kernel/sched

[PATCH v2 5/7] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

->clock_skip_update immediately before unpinning the rq lock. This will avoid the new warnings which check if update_rq_clock() is being actively skipped. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Signed-off-by: Matt Fleming --- kernel/sched/core.c | 5 - 1 file changed

[PATCH v2 2/7] sched/fair: Update rq clock before waking up new task

When initialising an entity's util and load averages we need an up to date runqueue clock. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Mel Gorman <mgor...@techsingularity.net> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Signed

[PATCH v2 2/7] sched/fair: Update rq clock before waking up new task

When initialising an entity's util and load averages we need an up to date runqueue clock. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel

[PATCH v2 3/7] sched/fair: Update rq clock in task_hot()

ularity.net> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/fair.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7f8a61e97599..85ca4ddab0d3 100644 --- a/kernel/s

[PATCH v2 3/7] sched/fair: Update rq clock in task_hot()

When determining whether or not a task is likely to be cache hot based on its execution start time, we need to ensure the runqueue task clock is accurate and up to date. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mel Gorman Cc: Mike Galbraith Signed-off-by: Matt Fleming --- kernel/sched/fair.c

[PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

.@techsingularity.net> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/core.c | 11 +--- kernel/sched/sched.h | 76 +++- 2 files changed, 77 insertions(+), 10 deletions(-) diff --git a/kernel/sched/core.c b/kernel/s

[PATCH v2 7/7] sched/core: Add debug code to catch missing update_rq_clock()

00 00movl $0x0,0x938(%rbx) - 00 00 00 + 83 a3 38 09 00 00 fcandl $0xfffc,0x938(%rbx) Suggested-by: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Signed-off-by: Matt Fleming --- kernel/sched/core.c | 11 +--- kernel/sched/sched.h | 76

[PATCH v2 0/7] sched: Diagnostic checks for missing rq clock updates

e I messed up the __schedule() ::clock_update_flags manipulation Matt Fleming (7): sched/fair: Update the rq clock before detaching tasks sched/fair: Update rq clock before waking up new task sched/fair: Update rq clock in task_hot() sched: Add wrappers for lockdep_(un)pin_lock() sche

[PATCH v2 0/7] sched: Diagnostic checks for missing rq clock updates

e I messed up the __schedule() ::clock_update_flags manipulation Matt Fleming (7): sched/fair: Update the rq clock before detaching tasks sched/fair: Update rq clock before waking up new task sched/fair: Update rq clock in task_hot() sched: Add wrappers for lockdep_(un)pin_lock() sche

Re: [GIT PULL 0/2] EFI urgent fixes

On Tue, 20 Sep, at 11:20:17AM, Waiman Long wrote: > On 09/20/2016 10:48 AM, Matt Fleming wrote: > >Folks, please pull the following two fixes that address the boot hang > >issue Waiman reported here, > > > > https://lkml.kernel.org/r/57df56d4.50...@hpe.com > &g

Re: [GIT PULL 0/2] EFI urgent fixes

On Tue, 20 Sep, at 11:20:17AM, Waiman Long wrote: > On 09/20/2016 10:48 AM, Matt Fleming wrote: > >Folks, please pull the following two fixes that address the boot hang > >issue Waiman reported here, > > > > https://lkml.kernel.org/r/57df56d4.50...@hpe.com > &g

[PATCH 1/2] x86/mm/pat: Prevent hang during boot when mapping pages

<a...@arndb.de> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Scott J Norton <scott.nor...@hpe.com> Cc: Douglas Hatch <doug.ha...@hpe.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/mm/pageattr.c | 21 +++-- 1 file changed, 11 i

[GIT PULL 0/2] EFI urgent fixes

) * Fix a boot hang on large memory machines (multiple terabyte) caused by type conversion errors in the x86 pat code - Matt Fleming Matt Fleming (2): x86/mm/pat: Prevent hang during boot when

[PATCH 2/2] x86/efi: Only map RAM into EFI page tables if in mixed-mode

ion.org> CC: Theodore Ts'o <ty...@mit.edu> Cc: Arnd Bergmann <a...@arndb.de> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Scott J Norton <scott.nor...@hpe.com> Cc: Douglas Hatch <doug.ha...@hpe.com> Cc: <sta...@vger.kernel.org> # v4.6+ Signed-o

[PATCH 1/2] x86/mm/pat: Prevent hang during boot when mapping pages

e value error checking idiom. Reported-by: Waiman Long Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Linus Torvalds CC: Theodore Ts'o Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Scott J Norton Cc: Douglas Hatch Signed-off-by: Matt Fleming --- arch/x86/mm/pageattr.c | 21 +++-- 1

[GIT PULL 0/2] EFI urgent fixes

) * Fix a boot hang on large memory machines (multiple terabyte) caused by type conversion errors in the x86 pat code - Matt Fleming Matt Fleming (2): x86/mm/pat: Prevent hang during boot when

[PATCH 2/2] x86/efi: Only map RAM into EFI page tables if in mixed-mode

: # v4.6+ Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c index 677e29e29473..8dd3784eb075 100644 --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86

[GIT PULL] EFI fix for v4.9 queue

) * Fix a boot crash reported by Mike Galbraith and Mike Krinkin. The new EFI memory map reservation code didn't align reservations to EFI_PAGE_SIZE boundaries causing bogus regions to be inserted into the global EFI memory map - Matt Fleming

[GIT PULL] EFI fix for v4.9 queue

) * Fix a boot crash reported by Mike Galbraith and Mike Krinkin. The new EFI memory map reservation code didn't align reservations to EFI_PAGE_SIZE boundaries causing bogus regions to be inserted into the global EFI memory map - Matt Fleming

[PATCH] x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE

Krinkin <krinkin@gmail.com> Tested-by: Mike Krinkin <krinkin@gmail.com> Cc: Peter Jones <pjo...@redhat.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Mark Rutland <mark.rutl...@arm.com> Cc: Taku Izumi <izumi.t...@jp.fujitsu.com> Signed-off-by: Matt Fleming &

[PATCH] x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE

Jones Cc: Ard Biesheuvel Cc: Mark Rutland Cc: Taku Izumi Signed-off-by: Matt Fleming --- arch/x86/platform/efi/quirks.c | 6 +- drivers/firmware/efi/memmap.c | 11 +++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/pl

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Mon, 19 Sep, at 01:09:22PM, Waiman Long wrote: > On 09/19/2016 10:51 AM, Matt Fleming wrote: > >On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote: > >>With this patch applied, I am able to successfully boot both the 16-socket > >>12-TB and 8-socket 6TB con

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Mon, 19 Sep, at 01:09:22PM, Waiman Long wrote: > On 09/19/2016 10:51 AM, Matt Fleming wrote: > >On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote: > >>With this patch applied, I am able to successfully boot both the 16-socket > >>12-TB and 8-socket 6TB con

Re: [PATCH] x86/efi: Add necessary checks before iterating over efi.memmap

On Tue, 20 Sep, at 01:25:14PM, Chao Gao wrote: > Sorry for bothering you. There is a regression since commit 78ce248f that if > booting xen in UEFI mode, dom0 will crash and xen reboot constantly. > This patch tries to fix it. Please take a look at it. Can you try commit d4c4fed08f31 ("efi: Make

Re: [PATCH] x86/efi: Add necessary checks before iterating over efi.memmap

On Tue, 20 Sep, at 01:25:14PM, Chao Gao wrote: > Sorry for bothering you. There is a regression since commit 78ce248f that if > booting xen in UEFI mode, dom0 will crash and xen reboot constantly. > This patch tries to fix it. Please take a look at it. Can you try commit d4c4fed08f31 ("efi: Make

Re: [PATCH] random: Fix kernel panic due to system_wq use before init

On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote: > > With this patch applied, I am able to successfully boot both the 16-socket > 12-TB and 8-socket 6TB configurations without problem. > > Tested-by: Waiman Long Could you please show your dmesg after booting with

<    1   2   3   4   5   6   7   8   9   10   >