On Tue, 2012-01-03 at 10:13 -0500, John David Anglin wrote:
> On 1/3/2012 6:50 AM, Carlos O'Donell wrote:
> > On Mon, Jan 2, 2012 at 6:12 PM, John David Anglin<dave.anglin@xxxxxxxx> wrote:
> >> None of this worked. Attached patch as it stands. Comments and testing
> >> appreciated.
> > Could you clarify what you mean by "none of this worked?"
> >
>
> I tried eliminating the flushes that occur in kunmap_atomic on PA8800
> and PA8900
> after the calls to clear_user_page and copy_user_page by defining
> clear_user_highpage
> and copy_user_highpage. I had thought the flushes weren't necessary.
> There's something
> about this that I don't understand. Why do we need to flush
> non-equivalent page mappings
> that aren't used?
But they are used: Your work makes sure that all user space mappings
are equivalent. However, because of the way Linux sets up kernel
mappings (from the pfn array and offsets) the user virtual address and
kernel virtual address almost never are. kmap is exclusively used so
the kernel can access a user page, and at that point, we need to flush
because we've set up an inequivalent alias (even if it's only done for
read)
kmap/kmap_atomic is used in more than just copy/flush ... or did you
mean that you removed the kmap calls in copy/flush and the whole thing
doesn't work (rather than as you imply you removed the flush in kunmap?)
> Also tried:
> #define flush_cache_dup_mm(mm) do { } while (0)
>
> In both cases, init died causing a panic at boot. Maybe there's
> something missing at
> startup.
>
> Most arch's have the above define for flush_cache_dup_mm. Our define
> really hurts
> fork performance. The GCC testsuite takes almost twice as long to run
> on linux as hpux.
> On the other hand, build times are fairly comparable.
I'll look into this, but I fear, because of the way the pa cache is
tagged, we'll have to keep the flush (same goes for flush_cache_mm).
James
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
