From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Dan Malek <dan@embeddededge.com>
Cc: "Smith, Craig" <craig.d.smith@siemens.com>,
paulus@samba.org,
linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: Linux 2.6.x on 8xx status
Date: Wed, 23 Mar 2005 07:25:01 -0300 [thread overview]
Message-ID: <20050323102501.GF7846@logos.cnet> (raw)
In-Reply-To: <ab78e7b7625e4293bf29fded17f589c2@embeddededge.com>
On Tue, Mar 22, 2005 at 05:53:40PM -0500, Dan Malek wrote:
>
> On Mar 22, 2005, at 12:58 PM, Marcelo Tosatti wrote:
>
> >Newbie question: What prevents the initial kernel map (tuple of 8Mbyte
> >I/D-TLB entries)
> >and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation
> >pressure,
> >in case CONFIG_PIN_TLB is disabled ?
>
> Nothing. In fact, they are likely invalidated shortly after the kernel
> page tables are set up. This was only done to ensure we could get the
> kernel initialized without taking page faults.
OK.
> >By a counter at the end of _tlbie function, similar to other counters
> >which
> >you suggested.
>
> OK.
>
> >Dont think thats the case given that v2.4 calls tlbia through
> >flush_tlb_mm() at exit_mmap()
> >only. And at vmalloc_free which shouldnt be called at all.
>
> Hmmm ... Then, the 2.6 looks to be much less efficient with the MMU
> resources than 2.4 was. This is going to affect everyone, it's just
> easier
> to measure on this processor.
Many codepaths are longer (eg. but the difference
>
> >I just noticed this conditional at switch_mm() (v2.6), which _can_
> >partly
> >explain the reduced tlbie's (its just a guess for now, though):
>
> What is your guess? I don't know how this would reduce the number
> of tlbie instructions, since stealing a context (as part of
> get_context())
> will simply whack the whole TLB with a tlbia. On 8xx, both instructions
> could be simply implemented as macros.
You misunderstood: get_mmu_context() _wont_ be called if the mm structures
are the same.
v2.4 didnt had this optimization.
> >Spent part of the day reading the MMU section of 860 manual, I think I
> >have kind
> >of a clue how things are supposed to work at the lowlevel now.
>
> :-)
>
> >PS: I can't reproduce the invalid TLB crash anymore. i.e. even by
> >removing
> >the _tlbie() at update_mmu_cache() everything is working as expected.
>
> Well, that's interesting. It's likely to only happen on an 860 variant
> that
> has the large TLB.
For what reasoning?
> >How can I reproduce it again? Guillaume, what kernel version are you
> >using?
>
> It used to happen on early 2.6 versions as soon as you entered user
> space programs.
Will let you know of any findings...
next prev parent reply other threads:[~2005-03-23 15:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 11:59 Linux 2.6.x on 8xx status Smith, Craig
2004-09-21 11:53 ` Pantelis Antoniou
2004-09-21 16:54 ` Dan Malek
2004-09-21 17:03 ` Dan Malek
2004-09-22 11:09 ` Sam Song
2004-10-15 15:49 ` Marcelo Tosatti
2004-10-16 2:13 ` Marcelo Tosatti
2004-10-16 9:08 ` Sam Song
2004-10-18 5:59 ` Pantelis Antoniou
2004-10-18 6:22 ` Sam Song
2004-10-18 3:10 ` Dan Malek
2005-02-10 15:04 ` Marcelo Tosatti
2005-02-10 19:26 ` Dan Malek
2005-02-10 17:06 ` Marcelo Tosatti
2005-02-10 17:08 ` Marcelo Tosatti
2005-03-21 21:45 ` Guillaume Autran
2005-03-21 21:53 ` Robert P. J. Day
2005-03-22 13:04 ` Marcelo Tosatti
2005-03-22 20:57 ` Dan Malek
2005-03-22 17:58 ` Marcelo Tosatti
2005-03-22 22:53 ` Dan Malek
2005-03-23 10:25 ` Marcelo Tosatti [this message]
2005-03-23 16:12 ` Dan Malek
2005-03-23 16:05 ` Marcelo Tosatti
2005-03-24 14:05 ` Pantelis Antoniou
2005-03-23 14:06 ` Guillaume Autran
2005-02-11 3:42 ` Dan Malek
2005-02-21 21:12 ` Armin Schindler
2005-02-21 23:45 ` Guillaume Autran
2005-02-15 9:39 ` Reading of RTC robin
-- strict thread matches above, loose matches on Subject: below --
2005-02-22 11:20 Linux 2.6.x on 8xx status Joakim Tjernlund
2004-10-25 15:00 Sam Song
2004-09-17 13:57 Smith, Craig
2004-09-17 13:50 ` Pantelis Antoniou
[not found] <20040916201505.E723B2BDB2@ozlabs.org>
2004-09-17 10:06 ` Song Sam
2004-09-17 9:55 ` Pantelis Antoniou
2004-09-18 20:11 ` Song Sam
2004-09-20 6:02 ` Pantelis Antoniou
2004-09-20 11:47 ` Song Sam
2004-09-20 17:49 ` Tom Rini
2004-09-20 18:02 ` Robert P. J. Day
2004-09-20 18:17 ` Tom Rini
2004-09-21 1:38 ` Song Sam
2004-09-21 6:12 ` Pantelis Antoniou
2004-09-21 10:35 ` Song Sam
2004-09-21 10:41 ` Pantelis Antoniou
2004-10-15 15:47 ` Marcelo Tosatti
2004-09-16 18:56 Smith, Craig
2004-09-16 20:07 ` Dan Malek
2004-09-17 5:43 ` Pantelis Antoniou
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=20050323102501.GF7846@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=craig.d.smith@siemens.com \
--cc=dan@embeddededge.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=paulus@samba.org \
/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.