All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 22 Mar 2005 14:58:15 -0300	[thread overview]
Message-ID: <20050322175815.GB7846@logos.cnet> (raw)
In-Reply-To: <f4f476b5e54e9f005dd28082bd5f16fe@embeddededge.com>

On Tue, Mar 22, 2005 at 03:57:08PM -0500, Dan Malek wrote:
> 
> On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:
> 
> >I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
> >less times than v2.4 ?

That was rather a _factor_ of "100-or-so" less.

> Oh my ...  I'm more worried about the high number of TLB misses
> in 2.6 compared to 2.4.  That's really bad.  

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 ? 

> How did you instrument the tlbie measurement? 

By a counter at the end of _tlbie function, similar to other counters which 
you suggested.

> It could be that 2.4 used lots more 'tlbia' which were replaced by tlbie in 2.6.

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.

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):

static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
                             struct task_struct *tsk)
{
#ifdef CONFIG_ALTIVEC
        asm volatile (
 BEGIN_FTR_SECTION
        "dssall;\n"
#ifndef CONFIG_POWER4
         "sync;\n" /* G4 needs a sync here, G5 apparently not */
#endif
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
         : : );
#endif /* CONFIG_ALTIVEC */
                                                                                            
        tsk->thread.pgdir = next->pgd;
                                                                                            
        /* No need to flush userspace segments if the mm doesnt change */
	if (prev == next) 				<--------------
		return;   				<--------------
                                                                                            
        /* Setup new userspace context */
        get_mmu_context(next);
        set_context(next->context, next->pgd);
}

I'm about to disable it and retry.

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. 

I'll continue tracking it down - any help is appreciated.

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.

How can I reproduce it again? Guillaume, what kernel version are you using?

  reply	other threads:[~2005-03-22 22:25 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 [this message]
2005-03-22 22:53                   ` Dan Malek
2005-03-23 10:25                     ` Marcelo Tosatti
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=20050322175815.GB7846@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.