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
next prev parent 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.