From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [RFC PATCH] ARM: Assume new page cache pages have dirty D-cache
Date: Fri, 5 Mar 2010 21:16:29 +0000 [thread overview]
Message-ID: <20100305211629.GF4885@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1267807960.2581.5.camel@e102109-lin.cambridge.arm.com>
On Fri, Mar 05, 2010 at 04:52:40PM +0000, Catalin Marinas wrote:
> As Ben said, I think we can set PG_dcache_clean in the
> clear/copy_user_page() functions. My doubt with these functions is the
> highmem cases where kunmap_atomic() only flushes the D-cache in one
> situation, the other just calling kunmap_high() which doesn't seem to do
> anything to the caches.
In which case you're totally missing the point with these functions.
The copy_user_page and clear_user_page functions specifically do tricks
to ensure that they can avoid additional cache maintainence - or any
cache maintainence at all.
For instance, on aliasing VIPT, they will map the user page in using
the same colour as the ultimate userspace address, ensuring that any
cache lines created will be visible to the userspace application.
So what kunmap_atomic() does with caches is not really relevant to the
coherency issue.
next prev parent reply other threads:[~2010-03-05 21:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 17:34 [RFC PATCH] ARM: Assume new page cache pages have dirty D-cache Catalin Marinas
2010-03-04 16:44 ` Russell King - ARM Linux
2010-03-04 17:27 ` Catalin Marinas
2010-03-04 18:36 ` Catalin Marinas
2010-03-04 21:44 ` Russell King - ARM Linux
2010-03-05 1:28 ` Paul Mundt
2010-03-05 4:46 ` Benjamin Herrenschmidt
2010-03-05 4:32 ` Benjamin Herrenschmidt
2010-03-05 16:52 ` Catalin Marinas
2010-03-05 21:16 ` Russell King - ARM Linux [this message]
2010-03-06 10:00 ` Catalin Marinas
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=20100305211629.GF4885@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=James.Bottomley@HansenPartnership.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox