All of lore.kernel.org
 help / color / mirror / Atom feed
From: michael <michael@evidence.eu.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Rafael Beims <rbeims@gmail.com>,
	Rex Feany <RFeany@mrv.com>
Subject: Re: mpc880 linux-2.6.32 slow running processes
Date: Thu, 06 Jan 2011 13:52:24 +0100	[thread overview]
Message-ID: <4D25BB08.7000001@evidence.eu.com> (raw)
In-Reply-To: <20110105174256.29fd378a@udp111988uds.am.freescale.net>

Hi

On 01/06/2011 12:42 AM, Scott Wood wrote:
> On Wed, 5 Jan 2011 19:23:33 +0100
> michael<michael@evidence.eu.com>  wrote:
>
>> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
>> index dd5ea95..cb67076 100644
>> --- a/arch/powerpc/include/asm/pte-8xx.h
>> +++ b/arch/powerpc/include/asm/pte-8xx.h
>> @@ -32,7 +32,7 @@
>>   #define _PAGE_FILE	0x0002	/* when !present: nonlinear file mapping */
>>   #define _PAGE_NO_CACHE	0x0002	/* I: cache inhibit */
>>   #define _PAGE_SHARED	0x0004	/* No ASID (context) compare */
>> -#define _PAGE_SPECIAL	0x0008	/* SW entry, forced to 0 by the TLB miss */
>> +#define _PAGE_SPECIAL	0x0000	/* SW entry, forced to 0 by the TLB miss */
> What do you think is going wrong with the special bit on 8xx?
>
> Or might the change to set_pte_filter() alone be what fixed the problem?
>
Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.
>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>> index 5304093..1da03a8 100644
>> --- a/arch/powerpc/mm/pgtable.c
>> +++ b/arch/powerpc/mm/pgtable.c
>> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
>>   	pte = __pte(pte_val(pte)&  ~_PAGE_HPTEFLAGS);
>>   	if (pte_looks_normal(pte)&&  !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
>>   				       cpu_has_feature(CPU_FTR_NOEXECUTE))) {
>> -		struct page *pg = maybe_pte_to_page(pte);
>> -		if (!pg)
>> +		unsigned long pfn = pte_pfn(pte);
>> +		struct page *pg;
>> +
>> +		if (unlikely(!pfn_valid(pfn)))
>>   			return pte;
>> -		if (!test_bit(PG_arch_1,&pg->flags)) {
>> +
>> +		pg = pfn_to_page(pfn);
>>   #ifdef CONFIG_8xx
>> -			/* On 8xx, cache control instructions (particularly
>> -			 * "dcbst" from flush_dcache_icache) fault as write
>> -			 * operation if there is an unpopulated TLB entry
>> -			 * for the address in question. To workaround that,
>> -			 * we invalidate the TLB here, thus avoiding dcbst
>> -			 * misbehaviour.
>> -			 */
>> -			/* 8xx doesn't care about PID, size or ind args */
>> -			_tlbil_va(addr, 0, 0, 0);
>> +		/* On 8xx, cache control instructions (particularly
>> +		 * "dcbst" from flush_dcache_icache) fault as write
>> +		 * operation if there is an unpopulated TLB entry
>> +		 * for the address in question. To workaround that,
>> +		 * we invalidate the TLB here, thus avoiding dcbst
>> +		 * misbehaviour.
>> +		 */
>> +		/* 8xx doesn't care about PID, size or ind args */
>> +		_tlbil_va(addr, 0, 0, 0);
>>   #endif /* CONFIG_8xx */
>> +
>> +		if (!pg)
>> +			return pte;
>> +
>> +		if (!PageReserved(pg)&&  !test_bit(PG_arch_1,&pg->flags)) {
>>   			flush_dcache_icache_page(pg);
>>   			set_bit(PG_arch_1,&pg->flags);
>>   		}
> Rex, do you recall under what specific circumstances the _tlbil_va is
> needed?  Is it possible that it will be caused by a dcbst in other
> contexts that are not dependent on the state of PG_arch_1?
>
> -Scott
>
Michael

  reply	other threads:[~2011-01-06 12:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 18:09 mpc880 linux-2.6.32 slow running processes Rafael Beims
2011-01-05 18:23 ` michael
     [not found]   ` <AANLkTi=uvunJ-ZFVGHZZExgBaNL9Sh0uZ3OiiCrcPnx=@mail.gmail.com>
2011-01-05 18:45     ` Fwd: " Rafael Beims
2011-01-05 19:13     ` michael
2011-01-05 23:42   ` Scott Wood
2011-01-06 12:52     ` michael [this message]
2011-01-06 16:52       ` Joakim Tjernlund
2011-01-07 10:00         ` Rafael Beims
2011-01-08 21:43           ` Joakim Tjernlund
2011-01-10 16:35             ` Rafael Beims
2011-01-10 16:55               ` Joakim Tjernlund
2011-01-11 16:00                 ` Joakim Tjernlund
2011-01-21  6:53                   ` Heiko Schocher
2011-01-22  9:50                     ` Joakim Tjernlund
2011-01-05 18:35 ` Wolfgang Denk
2011-01-05 18:50   ` Rafael Beims
2011-01-05 19:22   ` michael

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=4D25BB08.7000001@evidence.eu.com \
    --to=michael@evidence.eu.com \
    --cc=RFeany@mrv.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=rbeims@gmail.com \
    --cc=scottwood@freescale.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.