On 3/5/2015 7:15 AM, Julian Margetson wrote:
On 3/4/2015 7:52 PM, Michael Ellerman wrote:
On Wed, 2015-03-04 at 07:46 -0400, Julian Margetson wrote:
Still stuck.
Problem still exist with 4.0.0-rc2 and I cant finish the bisect.
Triggered when using HDMI. No problem when using DVI.
[ 33.535692]
On Sat, Mar 07, 2015 at 12:31:03PM -0800, Linus Torvalds wrote:
> On Sat, Mar 7, 2015 at 7:20 AM, Mel Gorman wrote:
> >
> > if (!prot_numa || !pmd_protnone(*pmd)) {
> > - ret = 1;
> > entry = pmdp_get_and_clear_notify(mm, addr, pmd);
>
On Sat, Mar 7, 2015 at 7:20 AM, Mel Gorman wrote:
>
> if (!prot_numa || !pmd_protnone(*pmd)) {
> - ret = 1;
> entry = pmdp_get_and_clear_notify(mm, addr, pmd);
> entry = pmd_modify(entry, newprot);
>
Looks obviously correct. The old code was just very wrong.
Acked-by: Linus Torvalds
Linus
On Sat, Mar 7, 2015 at 7:20 AM, Mel Gorman wrote:
> The wrong value is being returned by change_huge_pmd since commit
> 10c1045f28e8 ("mm: numa: avoid unnecessary TLB flushes when se
On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote:
>
> And the patch Dave bisected to is a relatively simple patch.
> Why not simply revert it to see whether that cures much of the
> problem?
So the problem with that is that "pmd_set_numa()" and friends simply
no longer exist. So we can't just re
On Sat, Mar 7, 2015 at 10:33 AM, Linus Torvalds
wrote:
>
> Completely untested, but that "just
> or in the new protection bits" is what pnf_pte() does just a few lines
> above this.
Hmm. Looking at this, we do *not* want to set _PAGE_ACCESSED when we
turn a page into PROT_NONE or mark
On Sat, Mar 7, 2015 at 7:20 AM, Mel Gorman wrote:
> pmd = pmd_modify(pmd, vma->vm_page_prot);
> + pmd = pmd_mkyoung(pmd);
Hmm. I *thought* this should be unnecessary. vm_page_prot alreadty has
the accessed bit set, and we kind of depend on the initial page table
setup and mk_pte() a
On Sat, Mar 07, 2015 at 05:36:58PM +0100, Ingo Molnar wrote:
>
> * Mel Gorman wrote:
>
> > Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
> >
> > Across the board the 4.0-rc1 numbers are much slower, and the
> > degradation is far worse when using the large memory fo
* Mel Gorman wrote:
> Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
>
> Across the board the 4.0-rc1 numbers are much slower, and the
> degradation is far worse when using the large memory footprint
> configs. Perf points straight at the cause - this is from 4.0-rc
The wrong value is being returned by change_huge_pmd since commit
10c1045f28e8 ("mm: numa: avoid unnecessary TLB flushes when setting
NUMA hinting entries") which allows a fallthrough that tries to adjust
non-existent PTEs. This patch corrects it.
Signed-off-by: Mel Gorman
---
mm/huge_memory.c |
Dave Chinner reported a problem due to excessive NUMA balancing activity
and bisected it. The first patch in this series corrects a major problem
that is unlikely to affect Dave but is still serious. Patch 2 is a minor
cleanup that was spotted while looking at scan rate control. Patch 3 is
minor an
Base PTEs are marked young when the NUMA hinting information is cleared
but the same does not happen for huge pages which this patch addresses.
Note that migrated pages are not marked young as the base page migration
code does not assume that migrated pages have been referenced. This could
be addre
Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
Across the board the 4.0-rc1 numbers are much slower, and the degradation
is far worse when using the large memory footprint configs. Perf points
straight at the cause - this is from 4.0-rc1 on the "-o bhash=101073" config:
This code is dead since commit 9e645ab6d089 ("sched/numa: Continue PTE
scanning even if migrate rate limited") so remove it.
Signed-off-by: Mel Gorman
---
include/linux/migrate.h | 5 -
mm/migrate.c| 20
2 files changed, 25 deletions(-)
diff --git a/include
Change 'prosessor' to 'processor'
Change 'set_inteval' to 'set_interval'
Signed-off-by: Yannick Guerrini
---
drivers/ps3/ps3-lpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ps3/ps3-lpm.c b/drivers/ps3/ps3-lpm.c
index b139b77..cb7d3a6 100644
--- a/drivers/ps3
On Thu, Feb 26, 2015 at 08:08:22PM +0800, Kevin Hao wrote:
> In the current kernel, the CONFIG_PPC_OF is always 'y' for the ppc
> arch. So we don't need to check it with other ppc specific options.
>
> Signed-off-by: Kevin Hao
> ---
> v2: No change.
>
> drivers/tty/serial/Kconfig | 4 ++--
> 1
Hi All,
I have a patch for it (Kernel 4.0-rc2):
diff -rupN linux-4.0/drivers/of/address.c
linux-4.0-nemo/drivers/of/address.c
--- linux-4.0/drivers/of/address.c2015-03-03 18:04:59.0 +0100
+++ linux-4.0-nemo/drivers/of/address.c2015-03-03 22:34:00.037500744
+0100
@@ -450,21 +4
It makes no sense to use a variant lock token on a platform which
doesn't support for shared-processor logical partitions. Actually we
can eliminate a memory load by using a fixed lock token on these
platforms.
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/spinlock.h | 8 ++--
1 file
All the cache line size of the current book3e 64bit SoCs are 64 bytes.
So we should use this size to align the member of paca_struct.
With this change we save 192 bytes. Also change it to __aligned(size)
since it is preferred over __attribute__((aligned(size))).
Before:
/* size: 1920, cach
On Fri, 2015-03-06 at 16:16 -0800, Alex Perez wrote:
> I will of course ultimately defer to Olof, but PASemi hasn’t existed
> for years, and there is no entity which could possibly update the DT
> for these reference PASemi development boards, unless Olof has source,
> which I’m pretty sure he doe
20 matches
Mail list logo