From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linuxppc-embedded@ozlabs.org, Dan Malek <dan@embeddedalley.com>
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
Date: Tue, 08 Nov 2005 07:39:59 +1100 [thread overview]
Message-ID: <1131396000.4652.24.camel@gaston> (raw)
In-Reply-To: <20051107084431.GA15180@logos.cnet>
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 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?
What do you mean by "one exception" version ? You probably get 3 in fact
since after you have serviced the fault in the common code, you take
another fault to fill the PTE.
In fact, you could even go back to one exception by pre-filling the TLB
in update_mmu_cache :)
> There is chance that the additional code ends up in the same cacheline,
> which would mean no huge gain by the "two exception" approach. Might be
> even harmful for performance (you need two exceptions instead of one
> after all).
>
> The "two exception" approach requires a TLB flush (to nuke the zeroed)
> at each PTE update for correct behaviour (which BTW is another slowdown):
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
Ben.
next prev parent reply other threads:[~2005-11-07 20:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-30 20:03 [PATCH 2.6.14] mm: 8xx MM fix for Pantelis Antoniou
2005-10-30 21:16 ` Benjamin Herrenschmidt
2005-11-01 17:25 ` Marcelo Tosatti
2005-11-01 22:55 ` Pantelis Antoniou
2005-11-02 9:50 ` Marcelo Tosatti
2005-11-07 8:44 ` Marcelo Tosatti
2005-11-07 14:35 ` Dan Malek
2005-11-07 10:27 ` Marcelo Tosatti
2005-11-07 14:39 ` Pantelis Antoniou
2005-11-07 14:58 ` David Jander
2005-11-07 20:39 ` Benjamin Herrenschmidt [this message]
2005-11-07 17:02 ` Marcelo Tosatti
2005-11-07 20:50 ` Pantelis Antoniou
2005-11-08 0:44 ` Dan Malek
2005-11-09 12:04 ` Marcelo Tosatti
2005-11-10 7:48 ` David Jander
2005-11-10 8:18 ` David Jander
-- strict thread matches above, loose matches on Subject: below --
2005-11-07 14:32 Joakim Tjernlund
2005-11-07 10:16 ` Marcelo Tosatti
2005-11-07 15:51 ` Tom Rini
2005-11-07 16:02 ` Dan Malek
2005-11-07 15:44 Joakim Tjernlund
2005-11-07 11:12 ` Marcelo Tosatti
2005-11-07 18:14 Joakim Tjernlund
2005-11-07 18:22 ` Tom Rini
2005-11-08 0:46 ` Dan Malek
2005-11-07 18:37 Joakim Tjernlund
2005-11-12 19:28 ` Marcelo Tosatti
2005-11-13 12:47 ` Joakim Tjernlund
2005-11-16 8:39 ` Marcelo Tosatti
2005-11-30 17:34 Joakim Tjernlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1131396000.4652.24.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=dan@embeddedalley.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=marcelo.tosatti@cyclades.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.