.crashing.org]
> > > > > Sent: 07 November 2005 16:52
> > > > > To: Marcelo Tosatti
> > > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > > linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> > > > >
alek; gtolstolytkin at ru.mvista.com;
> > linuxppc-embedded at ozlabs.org
> > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> >
> > On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> > > >
> > > > On Mon, Nov 07, 2005 at 07:14:15PM +0
> -Original Message-
> From: Marcelo Tosatti [mailto:marcelo.tosatti at cyclades.com]
> Sent: den 12 november 2005 20:28
> To: Joakim Tjernlund
> Cc: Tom Rini; Dan Malek; gtolstolytkin at ru.mvista.com;
> linuxppc-embedded at ozlabs.org
> Subject: Re: [PATCH 2.6.1
Sent: 07 November 2005 16:52
> > > > To: Marcelo Tosatti
> > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
&g
On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.
Sorry, I obviously did not me
On Wednesday 09 November 2005 13:04, Marcelo Tosatti wrote:
>[...]
>
> ** 2.6.14 DataTLBHandler jump direct ("two exceptions"):
>
> first batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> second batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> **
On Tue, Nov 08, 2005 at 07:39:59AM +1100, Benjamin Herrenschmidt wrote:
> I think the current code, even with your fix, is sub-optimal. But of
> course, the only way to be sure is to do real measurements
Hi folks,
I've written a simple app to estimate pagefault latency using gettimeofday().
Ca
On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> The bug is that the zeroed TLB is not invalidated (the same reason
> for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
I see, so you are in the same situation as ia64 which has valid but
unmapped TLBs ?
> Dan, I w
On Monday 07 November 2005 22:39, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> >
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
>
> I see, so you are
On Nov 7, 2005, at 1:22 PM, Tom Rini wrote:
> Assuming Dan doesn't come up with a more simple & better fix, maybe we
> should go back to the original patch I made?
I'm working on it. It'll look more like 2.4.
Thanks.
-- Dan
On Nov 7, 2005, at 3:50 PM, Pantelis Antoniou wrote:
> Yep. That should be the target. Remember the poor 8xx is not exactly a
> speed demon :).
It really isn't a big speed difference. The context save/restore
is minimal. The original thought was " ...well, I'm already here,
I know we will take
Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > >
> > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > >
> -Original Message-
> From: Tom Rini [mailto:trini at kernel.crashing.org]
> Sent: 07 November 2005 16:52
> To: Marcelo Tosatti
> Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> Subject: Re: [
On Monday 07 November 2005 09:44, Marcelo Tosatti wrote:
> Seems the bug is exposed by the change which avoids flushing the
> TLB when not necessary (in case the pte has not changed), introduced
> recently:
>[...]
Brilliant!
I just checked, and now it boots again.
Btw, it did boot before this patc
> Joakim!
>
> On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > Hi Marcelo
> >
> > [SNIP]
> > > The root of the problem are the changes against the 8xx TLB
> > > handlers introduced
> > > during v2.6. What happens is the TLBMiss handlers load the
> > > zeroed pte into
> >
Marcelo Tosatti wrote:
> Hi folks,
>
> Seems the bug is exposed by the change which avoids flushing the
> TLB when not necessary (in case the pte has not changed), introduced
> recently:
>
[snip]
>
>
Good job Marcelo! :)
FWIW I'd rather have the single exception version if at all possible.
Hi Marcelo
[SNIP]
> The root of the problem are the changes against the 8xx TLB
> handlers introduced
> during v2.6. What happens is the TLBMiss handlers load the
> zeroed pte into
> the TLB, causing the TLBError handler to be invoked (thats
> two TLB faults per
> pagefault), which then jumps
On Tue, Nov 08, 2005 at 07:39:59AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> >
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
>
> I see, so
lek;
> > linuxppc-embedded at ozlabs.org; gtolstolytkin at ru.mvista.com
> > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> >
> > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > Joakim!
> > >
> > > On Mon, Nov 07, 2005 at 03
On Nov 7, 2005, at 9:32 AM, Joakim Tjernlund wrote:
> This is one reason why it is the way it is:
Oh geeze, what a hack! :-) This could have been fixed
with a line of assembler code in the TLB miss exception.
I'll take a look at all of this and fix it up.
Thanks.
-- Dan
On Nov 7, 2005, at 3:44 AM, Marcelo Tosatti wrote:
> Dan, I wonder why we just don't go back to v2.4 behaviour. It is not
> very
> clear to me that "two exception" speedup offsets the additional code
> required
> for "one exception" version. Have you actually done any measurements?
No, and I d
On Mon, Nov 07, 2005 at 04:44:32PM +0100, Joakim Tjernlund wrote:
>
> > Joakim!
> >
> > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > Hi Marcelo
> > >
> > > [SNIP]
> > > > The root of the problem are the changes against the 8xx TLB
> > > > handlers introduced
> > > >
On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> Joakim!
>
> On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > Hi Marcelo
> >
> > [SNIP]
> > > The root of the problem are the changes against the 8xx TLB
> > > handlers introduced
> > > during v2.6. What happ
On Mon, Nov 07, 2005 at 09:35:59AM -0500, Dan Malek wrote:
>
> On Nov 7, 2005, at 3:44 AM, Marcelo Tosatti wrote:
>
> >Dan, I wonder why we just don't go back to v2.4 behaviour. It is not
> >very
> >clear to me that "two exception" speedup offsets the additional code
> >required
> >for "one exc
Joakim!
On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> Hi Marcelo
>
> [SNIP]
> > The root of the problem are the changes against the 8xx TLB
> > handlers introduced
> > during v2.6. What happens is the TLBMiss handlers load the
> > zeroed pte into
> > the TLB, causing the
Hi folks,
Seems the bug is exposed by the change which avoids flushing the
TLB when not necessary (in case the pte has not changed), introduced
recently:
__handle_mm_fault():
entry = pte_mkyoung(entry);
if (!pte_same(old_entry, entry)) {
ptep_set_access_flags(vma,
On Wed, Nov 02, 2005 at 12:55:57AM +0200, Pantelis Antoniou wrote:
> On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> > On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > > Latest MMU changes caused 8xx to stop working. Flushing tlb of the
> > > faulting
> > > addres
On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> > address fixes the problem.
>
> Hi Panto,
>
> Its working fine around here. How much of
On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> address fixes the problem.
Hi Panto,
Its working fine around here. How much of a vanilla 2.6.14 your is?
[root at CAS root]# cat /proc/cpuinfo
proces
On Sun, 2005-10-30 at 23:03 +0300, Pantelis Antoniou wrote:
> Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> address fixes the problem.
Ugh ?
What is the problem precisely ? This is just a dodgy workaround for an
unexplained problem. Normally, the kenrel _WILL_ caus
Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
address fixes the problem.
---
commit 978e2f36b1ae53e37ba27b3ab8f1c5ddbb8c8a10
tree 7dd0e403c240162b1925db0834d694f4b4a0e95e
parent ca02ea5aebcda886d1552c6af73ca96c02bf9fed
author Pantelis Antoniou Sun, 30 Oct 2005 21:53:
31 matches
Mail list logo
