Date: Tue, 9 Sep 2008 18:23:59 +0200 From: "Jacques Fourie" <jacques.fourie@gmail.com> To: "Mark Tinguely" <tinguely@casselton.net> Cc: freebsd-arm@freebsd.org, sam@freebsd.org Subject: Re: Routing benchmarks Message-ID: <be2f52430809090923hb315069u2f3628ecf78dda60@mail.gmail.com> In-Reply-To: <200809091614.m89GEAc4088266@casselton.net> References: <be2f52430809090816v57c2c80u6a48446b1e875361@mail.gmail.com> <200809091614.m89GEAc4088266@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 9, 2008 at 6:14 PM, Mark Tinguely <tinguely@casselton.net> wrote: > > (trimmed the thread text) > >> >> Running netserver on the gumstix shows a throughput of 2.4Mbit/s. At >> >> the moment I can't get if_bridge to work - will try to figure out what >> >> is going on. A bridging benchmark may be more informative. > >> > My experience in working with architectures like this is that cache handling >> > can be a significant cost that doesn't always show up on a profile. >> > >> >> Thanks for the nice idea - will try something similar. At the moment >> I'm also suspecting that cache handling has got a lot to do with the >> performance figures that I'm seeing. The PXA255 has a 32KB data and >> 32KB instruction cache. >> >> Jacques > > which version of freebsd are you using - we changed some cache flushing > routines between FreeBSD 7.x and current. Unless errors were introduced > or removed, there should not be that large of a change. > > As mentioned, the ARM caches are pretty small. The ARM processors before > version 6, (anything before ARM10) uses virtually indexed / virtually tagged > caches, so they need to be flushed on context changes. > > The version 6 and version 7 ARM processors (ARM10/ARM11) are either virtually > indexed / physically tagged or physically indexed / physically tagged. > The PIPT caches don't need to be flushed on context changes and were needed > for multiple processor support. The pmap code will have to be re-written to > take advantage of the PIPT caches (put a process value into the MMU and remove > most flushes). > > Also, the pre version 6 ARM processors didn't allow for any spare bits in the > PTE for OS use. The newer processors have a bit or two, still not enough > for FreeBSD's needs, so we need to shadow these bits. > > Thirdly, we dynamically allocate a seperate structure that mirrors the > page table. I think I have all the "paper scratching" required to move from > this structure to the FreeBSD i386/amd64 recursive page table approach. > > --Mark Tinguely. > I'm using -current from about a week ago. Jacques
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be2f52430809090923hb315069u2f3628ecf78dda60>