All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Autran <gautran@mrv.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.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 09:06:51 -0500	[thread overview]
Message-ID: <424177FB.7090101@mrv.com> (raw)
In-Reply-To: <20050322175815.GB7846@logos.cnet>

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]



Marcelo Tosatti wrote:

>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?
>
>  
>
It is very timing dependant. Running 2.6.11, ldconfig crashes in 
__flush_dcache_icache(...) just after boot time (first time called). 
Unfortunatly, it only happens every now and then. And of course, never 
when my BDI2000 is plugged in. :(

I also noticed that with kernel preemption disable, oops are less 
frequent. Probably does not mean anything anyway...

Guillaume.


-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
======================================= 


[-- Attachment #2: Type: text/html, Size: 4130 bytes --]

  parent reply	other threads:[~2005-03-23 14:06 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
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 [this message]
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=424177FB.7090101@mrv.com \
    --to=gautran@mrv.com \
    --cc=craig.d.smith@siemens.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=marcelo.tosatti@cyclades.com \
    --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.