From: Thiemo Seufer <ths@networkno.de>
To: Luc Perneel <lper.home@gmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Cache aliasing issues using 4K pages.
Date: Tue, 15 Jan 2008 11:57:22 +0000 [thread overview]
Message-ID: <20080115115721.GA31107@networkno.de> (raw)
In-Reply-To: <1a18fe6d0801142250h7ce58675i2bce7cb2e2db2669@mail.gmail.com>
Luc Perneel wrote:
> On Jan 15, 2008 2:58 AM, Thiemo Seufer <ths@networkno.de> wrote:
>
> > The Engineer wrote:
> > > We are working with a 2.6.12 kernel on a dual-core mips architecture.
> > > In this dual-core system, one core is running the linux kernel and the
> > > other is used for some real-time handling (not directly controlled by
> > > Linux)
> > > We had different stability issues, which could be pinpointed to be
> > > related with cache aliasing problems.
> > > Cache aliasing happens when the same physical memory can be cached
> > > twice as it is accessed by two different virtual addresses.
> > > Indeed, for the index to select the correct cache line the virtual
> > > address is used. If some bits of the virtual page address are used in
> > > the cache index, aliasing can occur.
> > >
> > >
> > > As there is no hardware solution in the mips to recover from this
> > > (which would provide some cache coherency, even for one core), the
> > > only intrinsic safe solution is to enlarge the page size, so that
> > > cache indexing is only done by the offset address in the page (thus
> > > the physical part of the address).
> > > Another solution is to flush the cache if a page is being remapped to
> > > an aliased address (but in our case linux does not has control on the
> > > second core, which can cause issues with shared data between both
> > > cores).
> > > Currently the second solution is used in the kernel, but we found
> > > different issues with it (for instance: we had to merge more recent
> > > mips kernels, to get a reliable copy-on-write behaviour after
> > > forks...).
> > >
> > > Therefore some questions:
> > > - Are there still some known issues with cache aliasing in the MIPS
> > kernel?
> > > - Are there known issues when using 16KB pages (8KB pages seems not be
> > > possible due to tlb issues).
> >
> > With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12
> > kernel however you'll have to backport a serious amount of bugfixes
> > before 16k pages can work. Upgrading the kernel is probably less work.
> >
> > Thiemo
> >
> Thanks for the info, any idea from which kernel this works ok?
I believe the linux-2.6.22-stable branch from www.linux-mips.org is the
best version to use. I don't recall if the earlier branches got all the
necessary fixes.
Thiemo
prev parent reply other threads:[~2008-01-15 11:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-14 20:25 Cache aliasing issues using 4K pages The Engineer
2008-01-14 22:34 ` [SPAM] " Markus Gothe
2008-01-15 6:34 ` Luc Perneel
2008-01-15 1:58 ` Thiemo Seufer
2008-01-15 6:50 ` Luc Perneel
2008-01-15 11:57 ` Thiemo Seufer [this message]
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=20080115115721.GA31107@networkno.de \
--to=ths@networkno.de \
--cc=linux-mips@linux-mips.org \
--cc=lper.home@gmail.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.