Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 04/10/2009 22:28:38:
I have managed to update the TLB code to make proper use of dirty and
accessed states.
Advantages are:
- I/D TLB Miss never needs to write to the linux pte, saving a few cycles
That's good, that leaves us
Scott Wood scottw...@freescale.com wrote on 05/10/2009 20:24:29:
On Sat, Oct 03, 2009 at 10:05:46AM +0200, Joakim Tjernlund wrote:
Scott Wood scottw...@freescale.com wrote on 02/10/2009 23:49:49:
Adding a tlbil_va to do_page_fault makes the problem go away for me (on
top of your merge
On Sat, Oct 03, 2009 at 08:04:33AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2009-10-02 at 16:49 -0500, Scott Wood wrote:
Adding a tlbil_va to do_page_fault makes the problem go away for me (on
top of your merge branch) -- none of the other changes in this thread
do (assuming I didn't
On Mon, 2009-10-05 at 21:16 +0200, Joakim Tjernlund wrote:
Ben, for my understanding: It seems to that the TLB Miss routines in
head_32.S are less than optimal as it too touches the pte every time
it hits. Would it not be better to test if ACCESSED and friends are
already set
and skip storing
On Mon, 2009-10-05 at 14:28 -0500, Scott Wood wrote:
Yes, it hits ptep_set_access_flags() and adding _tlbil_va there helps (I
didn't put it in the filter function, because that doesn't take address as a
parameter). I'd misread your suggestion as referring to the various changes
to
Benjamin Herrenschmidt wrote:
On Mon, 2009-10-05 at 14:28 -0500, Scott Wood wrote:
Yes, it hits ptep_set_access_flags() and adding _tlbil_va there helps (I
didn't put it in the filter function, because that doesn't take address as a
parameter). I'd misread your suggestion as referring to the
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 03/10/2009 12:57:28:
On Sat, 2009-10-03 at 11:24 +0200, Joakim Tjernlund wrote:
So yes, there is a missing _tlbil_va() missing for 8xx somewhere
but there is something more too.
Maybe your new filter functions and my
powerpc,
Scott Wood scottw...@freescale.com wrote on 02/10/2009 23:49:49:
On Thu, Oct 01, 2009 at 08:35:59AM +1000, Benjamin Herrenschmidt wrote:
From what I can see, the TLB miss code will check _PAGE_PRESENT, and
when not set, it will -still- insert something into the TLB (unlike
all other CPU
On Sun, 2009-10-04 at 10:35 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 03/10/2009
12:57:28:
On Sat, 2009-10-03 at 11:24 +0200, Joakim Tjernlund wrote:
So yes, there is a missing _tlbil_va() missing for 8xx somewhere
but there is
I have managed to update the TLB code to make proper use of dirty and
accessed states.
Advantages are:
- I/D TLB Miss never needs to write to the linux pte, saving a few cycles
That's good, that leaves us with only 40x to fix now. Also we can remove
atomic updates of PTEs for all non-hash.
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 04/10/2009 22:26:42:
On Sun, 2009-10-04 at 10:35 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 03/10/2009
12:57:28:
On Sat, 2009-10-03 at 11:24 +0200, Joakim Tjernlund wrote:
So
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 04/10/2009 22:28:38:
I have managed to update the TLB code to make proper use of dirty and
accessed states.
Advantages are:
- I/D TLB Miss never needs to write to the linux pte, saving a few cycles
That's good, that leaves us
Scott Wood scottw...@freescale.com wrote on 02/10/2009 23:49:49:
On Thu, Oct 01, 2009 at 08:35:59AM +1000, Benjamin Herrenschmidt wrote:
From what I can see, the TLB miss code will check _PAGE_PRESENT, and
when not set, it will -still- insert something into the TLB (unlike
all other CPU
On Sat, 2009-10-03 at 10:05 +0200, Joakim Tjernlund wrote:
Cannot shake the feeling that it this snip of code that causes it
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page
address */
beq 2f
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 03/10/2009 10:31:18:
On Sat, 2009-10-03 at 10:05 +0200, Joakim Tjernlund wrote:
Cannot shake the feeling that it this snip of code that causes it
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10,
On Sat, 2009-10-03 at 11:24 +0200, Joakim Tjernlund wrote:
So yes, there is a missing _tlbil_va() missing for 8xx somewhere
but there is something more too.
Maybe your new filter functions and my
powerpc, 8xx: DTLB Error must check for more errors.
will do the trick?
Well, if we can't
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 03/10/2009 12:57:28:
On Sat, 2009-10-03 at 11:24 +0200, Joakim Tjernlund wrote:
So yes, there is a missing _tlbil_va() missing for 8xx somewhere
but there is something more too.
Maybe your new filter functions and my
powerpc,
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 01/10/2009
00:35:59:
Had a look at linus tree and there is something I don't understand.
Your fix, e0908085fc2391c85b85fb814ae1df377c8e0dcb, fixes a problem
that was introduced by 8d30c14cab30d405a05f2aaceda1e9ad57800f36
On Thu, Oct 01, 2009 at 08:35:59AM +1000, Benjamin Herrenschmidt wrote:
From what I can see, the TLB miss code will check _PAGE_PRESENT, and
when not set, it will -still- insert something into the TLB (unlike
all other CPU types that go straight to data access faults from there).
So we end
On Fri, 2009-10-02 at 16:49 -0500, Scott Wood wrote:
Adding a tlbil_va to do_page_fault makes the problem go away for me (on
top of your merge branch) -- none of the other changes in this thread
do (assuming I didn't miss any). FWIW, when it gets stuck on a fault,
DSISR is 0xc000, and
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 01/10/2009 00:35:59:
Had a look at linus tree and there is something I don't understand.
Your fix, e0908085fc2391c85b85fb814ae1df377c8e0dcb, fixes a problem
that was introduced by 8d30c14cab30d405a05f2aaceda1e9ad57800f36 but
Rex Feany rfe...@mrv.com wrote on 29/09/2009 23:03:31:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009
10:16:38:
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other
Rex Feany rfe...@mrv.com wrote on 29/09/2009 23:03:31:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009
10:16:38:
hmm, yes. You do get this and mysterious SEGV if you hit the but so
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Ok, I have made some minor tweaks and added debug code in
do_page_fault(). Would be great if you could try on both
.31 and top of tree.
Jocke
OOPS, found a bug. Use this one instead:
.31 - no change, it worked before your
Rex Feany rfe...@mrv.com wrote on 30/09/2009 11:00:02:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Ok, I have made some minor tweaks and added debug code in
do_page_fault(). Would be great if you could try on both
.31 and top of tree.
Jocke
OOPS, found a
Rex Feany rfe...@mrv.com wrote on 30/09/2009 11:00:02:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Ok, I have made some minor tweaks and added debug code in
do_page_fault(). Would be great if you could try on both
.31 and top of tree.
Jocke
OOPS, found a
Rex Feany rfe...@mrv.com wrote on 30/09/2009 11:00:02:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Ok, I have made some minor tweaks and added debug code in
do_page_fault(). Would be great if you could try on both
.31 and top of tree.
Jocke
OOPS,
Had a look at linus tree and there is something I don't understand.
Your fix, e0908085fc2391c85b85fb814ae1df377c8e0dcb, fixes a problem
that was introduced by 8d30c14cab30d405a05f2aaceda1e9ad57800f36 but
8d30c14cab30d405a05f2aaceda1e9ad57800f36 was included in .31 and .31
works and top
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
On Thu, 2009-09-24 at 18:35 -0700, Rex Feany wrote:
Then I can boot and get to a shell, but userspace is slow. 8 seconds
to mount
/proc (vs. less then a second using my old kernel)! Maybe this is an
unrelated issue?
On Mon, 2009-09-28 at 18:21 -0700, Rex Feany wrote:
It's going to be hard for me to get that right since I don't really
know what's going on with the core here, but I suppose if we get it
moving along with extra tlb invalidations, that should be good enough
until somebody who really knows
On Tue, 2009-09-29 at 08:26 +0200, Joakim Tjernlund wrote:
I've tried sticking tlbil_va() in those places, nothing seems to
help.
In some cases userspace is slow, in other cases userspace is faster
and
unstable: sometimes commands hang, sometimes I am able to ctrl-c and
and kill it,
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009 09:07:37:
On Tue, 2009-09-29 at 08:26 +0200, Joakim Tjernlund wrote:
I've tried sticking tlbil_va() in those places, nothing seems to
help.
In some cases userspace is slow, in other cases userspace is faster
and
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other bugs too so this is probably due to missing invalidation.
I suspect that something like below will fix the problem and
is the correct fix(untested, not even compiled):
Ok but do we also still have to worry about
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009 10:16:38:
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other bugs too so this is probably due to missing invalidation.
I suspect that something like below will fix the problem and
is the
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009 10:16:38:
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other bugs too so this is probably due to missing invalidation.
I suspect that something like below will fix the problem and
is the
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009
10:16:38:
hmm, yes. You do get this and mysterious SEGV if you hit the but so does
other bugs too so this is probably due to missing invalidation.
I
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
On Mon, 2009-09-28 at 18:21 -0700, Rex Feany wrote:
It's going to be hard for me to get that right since I don't really
know what's going on with the core here, but I suppose if we get it
moving along with extra tlb
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 28/09/2009 05:21:00:
On Sun, 2009-09-27 at 15:22 +0200, Joakim Tjernlund wrote:
However, adding tlbil_va() to ptep_set_access_flags() as you suggested
makes everything happy. I need to test it some more, but it looks good
so far.
On Mon, 2009-09-28 at 09:22 +0200, Joakim Tjernlund wrote:
happy to stick with it until somebody comes up with a real good
reason
to do more :-) 8xx is on life support and has been around for long
yeah, I figured that too but Freescale seems to be cranking out new
variants still.
Ugh ?
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 28/09/2009 09:34:46:
On Mon, 2009-09-28 at 09:22 +0200, Joakim Tjernlund wrote:
happy to stick with it until somebody comes up with a real good
reason
to do more :-) 8xx is on life support and has been around for long
yeah, I
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 28/09/2009
05:21:00:
On Sun, 2009-09-27 at 15:22 +0200, Joakim Tjernlund wrote:
However, adding tlbil_va() to ptep_set_access_flags() as you suggested
makes everything happy. I need to test it some more, but it looks good
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
On Thu, 2009-09-24 at 18:35 -0700, Rex Feany wrote:
Then I can boot and get to a shell, but userspace is slow. 8 seconds
to mount
/proc (vs. less then a second using my old kernel)! Maybe this is an
unrelated issue? I'm
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
I think there's more finishyness to 8xx than we thought. IE. That
tlbil_va might have more reasons to be there than what the comment
seems to advertize. Can you try to move it even higher up ? IE.
Unconditionally at the
On Sun, 2009-09-27 at 15:22 +0200, Joakim Tjernlund wrote:
However, adding tlbil_va() to ptep_set_access_flags() as you suggested
makes everything happy. I need to test it some more, but it looks good
so far. Below is what I am testing now.
8xx, is getting very hacky and I suspect that
I think there's more finishyness to 8xx than we thought. IE. That
tlbil_va might have more reasons to be there than what the comment
seems to advertize. Can you try to move it even higher up ? IE.
Unconditionally at the beginning of set_pte_filter ?
Also, if that doesn't help, can
On Fri, 2009-09-25 at 10:31 +0200, Joakim Tjernlund wrote:
The main problem with 8xx it does not update the DAR register in
the TLB Miss/Fault handlers for cache instructions :( It on old bug
that was found only some years ago.
I think the old comment is correct though, as I recall it was
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 25/09/2009 11:47:34:
On Fri, 2009-09-25 at 10:31 +0200, Joakim Tjernlund wrote:
The main problem with 8xx it does not update the DAR register in
the TLB Miss/Fault handlers for cache instructions :( It on old bug
that was found
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
I think there's more finishyness to 8xx than we thought. IE. That
tlbil_va might have more reasons to be there than what the comment
seems to advertize. Can you try to move it even higher up ? IE.
Unconditionally at the
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
You can get my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
(To get the merge branch, just add merge after the clone if you
are cloning it, or just create a local branch and manually pull
into it)
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
Your tree hangs on boot, similar to what I saw without the 8xx
work-around patch -- it is hard to tell if it is the same though. :(
There's no backtrace ? Where does it hang ? Also which workaround
patch ? The missing
On Thu, 2009-09-24 at 18:35 -0700, Rex Feany wrote:
Then I can boot and get to a shell, but userspace is slow. 8 seconds
to mount
/proc (vs. less then a second using my old kernel)! Maybe this is an
unrelated issue? I'm pretty clueless about the details, I'm sorry.
PG_arch_1 is used to
I think there's more finishyness to 8xx than we thought. IE. That
tlbil_va might have more reasons to be there than what the comment
seems to advertize. Can you try to move it even higher up ? IE.
Unconditionally at the beginning of set_pte_filter ?
Also, if that doesn't help, can you try
After upgrading to the latest kernel on my mpc875 userspace started
running incredibly slow (hours to get to a shell, even!).
I tracked it down to commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36,
that patch removed a work-around for the 8xx. Adding it
back makes my problem go away.
Signed-off-by:
53 matches
Mail list logo
