From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Helge Deller <deller@gmx.de>
Cc: Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: parisc: flush pages through tmpalias space
Date: Wed, 29 Dec 2010 08:49:43 -0600 [thread overview]
Message-ID: <1293634183.2803.2.camel@fuzzy> (raw)
In-Reply-To: <4D166793.30901@gmx.de>
On Sat, 2010-12-25 at 22:52 +0100, Helge Deller wrote:
> On 12/22/2010 05:22 PM, James Bottomley wrote:
> > The kernel has an 8M tmpailas space (originally designed for copying
> > and clearing pages but now only used for clearing). The idea is
> > to place zeros into the cache above a physical page rather than into
> > the physical page and flush the cache, because often the zeros end up
> > being replaced quickly anyway.
> >
> > We can also use the tmpalias space for flushing a page. The difference
> > here is that we have to do tmpalias processing in the non access data and
> > instruction traps. The principle is the same: as long as we know the physical
> > address and have a virtual address congruent to the real one, the flush will
> > be effective.
> >
> > In order to use the tmpalias space, the icache miss path has to be enhanced to
> > check for the alias region to make the fic instruction effective.
> >
> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>
>
> Hi James,
>
> Cool, I assume this patch intends to fix the "Threads and fork on
> VIPT-WB machines" bug as described here:
> http://wiki.parisc-linux.org/TestCases ?
Well, not really ... it's meant to provide data to fix that case. The
theory behind them is that if we flush in the wrong place (say after the
mapping has been torn down), then the flush becomes ineffective. The
idea of flushing through the tmpalias space is that the flush becomes
effective regardless of placement. I didn't really think we had any
ineffective flushes, but it's good to demonstrate that.
> I did some initial testing and it seems to really fix it...
> I'll continue testing during the next few days (with 2.6.37-rc7-32bit).
That's an interesting data point ... it certainly doesn't fix the
problem with me on pa8800 SMP.
James
next prev parent reply other threads:[~2010-12-29 14:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 16:22 parisc: flush pages through tmpalias space James Bottomley
2010-12-23 0:07 ` Carlos O'Donell
2010-12-23 3:04 ` John David Anglin
2010-12-25 21:52 ` Helge Deller
2010-12-29 14:49 ` James Bottomley [this message]
2010-12-29 4:23 ` John David Anglin
2010-12-29 14:51 ` James Bottomley
2010-12-30 15:56 ` John David Anglin
2010-12-30 16:09 ` John David Anglin
2011-01-01 18:31 ` John David Anglin
2011-01-01 19:00 ` John David Anglin
2011-01-05 3:49 ` John David Anglin
2011-01-05 17:37 ` Carlos O'Donell
2011-01-05 18:51 ` John David Anglin
2011-01-09 21:27 ` John David Anglin
2011-01-09 21:52 ` John David Anglin
2011-01-10 20:44 ` James Bottomley
2011-01-10 22:18 ` John David Anglin
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=1293634183.2803.2.camel@fuzzy \
--to=james.bottomley@hansenpartnership.com \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.org \
/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.