From: Wolfgang Grandegger <wolfgang.grandegger@bluewin•ch>
To: Matt Porter <mporter@kernel•crashing.org>
Cc: linuxppc-embedded@lists•linuxppc.org
Subject: Re: 405 TLB miss reduction
Date: Fri, 12 Dec 2003 10:50:06 +0100 [thread overview]
Message-ID: <3FD98F4E.9080602@bluewin.ch> (raw)
In-Reply-To: 20031211104505.C26110@home.com
On 12/11/2003 06:45 PM Matt Porter wrote:
> On Thu, Dec 11, 2003 at 10:06:32AM +0100, Wolfgang Grandegger wrote:
>>
>> On 12/10/2003 05:03 PM Matt Porter wrote:
>> > David Gibson and Paul M. implemented large TLB kernel lowmem
>> > support in 2.5/2.6 for 405. It allows for large TLB entries
>> > to be loaded on kernel lowmem TLB misses. This is better than
>> > the CONFIG_PIN_TLB since it works for all of your kernel lowmem
>> > system memory rather than the fixed amount of memory that
>> > CONFIG_PIN_TLB covers.
>>
>> Ah, I will have a look to 2.5/2.6. Is there a backport for 2.4?
>
> No.
>
>> > I've been thinking about enabling a variant of Andi Kleen's patch
>> > to allow modules to be loaded into kernel lowmem space instead of
>> > vmalloc space (to avoid the performance penalty of modular drivers).
>> > This takes advantage of the large kernel lowmem 405 support above
>> > and on 440 all kernel lowmem is in a pinned tlb for architectural
>> > reasons.
>>
>> Is this patch available somewhere? It would be interesting to measure
>> the improvement for our application.
>
> Google is your friend.
> http://seclists.org/lists/linux-kernel/2002/Oct/6522.html
> IIRC, there's a later version with some minor differences.
>
>> > I've also been thinking about dynamically using large TLB/PTE mappings
>> > for ioremap on 405/440.
>>
>> OK, I expect not so much benefit from this measure but it depends on the
>> application, of course.
>
> Yes, I've seen a lot of apps with huge shared memory areas across PCI
> that can benefit from this...they used BATs on classic PPCs.
>
>> > In 2.6, there is hugetlb userspace infrastructure that could be enabled
>> > for the large page sizes on 4xx.
>>
>> But this sounds more promising. Same questing as above. Is there a
>> backport for 2.4?
>
> No.
>
>> > Allowing a compile time choice of default page size would also be useful.
>>
>> Increasing the page size from 4 to 8 kB should, in theory, halve the
>> page misses (if no large TLB pages are used). Unfortunately, increasing
>> the page size seem not straight forward as it's statically used in
>> various places and maybe the GLIBC needs to be rebuild as well.
>
> Possibly, as Dan mentions, there are other arches already doing this
> type of thing. I know ia64 does and sounds like MIPS is another.
>
>> > Basically, all of these cases can provide a performance advantage
>> > depending on your embedded application...it all depends on what your
>> > application is doing.
>>
>> Of course, and tweaking the kernel for a dedicated application might not
>> been worth the effort. Anyhow, I have now a better idea what else can be
>> done.
>
> When I used to do apps work we were very performance sensitive (depends
> on you project, of course) and we were very willing to make kernel
> tweaks (proprietary RTOS) to me our requirements. It all depends on
> your requirements, constraints, budget, etc. :)
Well, time and money is usually a scarce resource :-(. Anyhow, this
thread showed me that it might be worth tweaking the kernel and that
there are already various implementations which could be followed after
a more detailed analysis of the TLB misses. Thank you and Dan very much
for the valuable input.
Wolfgang.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-12-12 9:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-10 14:43 405 TLB miss reduction Wolfgang Grandegger
2003-12-10 16:03 ` Matt Porter
2003-12-11 9:06 ` Wolfgang Grandegger
2003-12-11 15:46 ` Dan Malek
2003-12-11 17:45 ` Matt Porter
2003-12-12 9:50 ` Wolfgang Grandegger [this message]
2003-12-15 11:26 ` Joakim Tjernlund
2003-12-10 17:08 ` Dan Malek
2003-12-11 10:37 ` Wolfgang Grandegger
2003-12-11 16:48 ` Jon Masters
2003-12-11 16:56 ` Wolfgang Grandegger
2003-12-11 17:06 ` Jon Masters
2003-12-11 17:36 ` Matt Porter
2003-12-11 16:44 ` Jon Masters
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=3FD98F4E.9080602@bluewin.ch \
--to=wolfgang.grandegger@bluewin$(echo .)ch \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
--cc=mporter@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox