All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Naval Saini <navalnovel@gmail.com>,
	linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org, naval.saini@nxp.com,
	James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: O_DIRECT patch for processors with VIPT cache for mainline kernel (specifically arm in our case)
Date: Thu, 20 Nov 2008 17:17:14 +0000	[thread overview]
Message-ID: <20081120171713.GB27398@linux-mips.org> (raw)
In-Reply-To: <20081120152719.GS1617@parisc-linux.org>

On Thu, Nov 20, 2008 at 08:27:19AM -0700, Matthew Wilcox wrote:

> I'm not quite sure why you need kmap_coherent().  If a page is mapped into
> userspace, you can find what address it's mapped to from
> page->mapping->i_mmap and page->index.  OTOH, that's potentially

Even if we know the userspace address of a page we do not necessarily have
a usable mapping for kernel purposes.  The userspace mapping might be r/o
when we need r/w or it might be in another process.  kmap_coherent takes
the job of creating a r/w mapping on a suitable kernel virtual address
that will avoid any aliases.

> page->mapping->i_mmap and page->index.  OTOH, that's potentially
> expensive since you need to grab the spinlock, and unless you have all
> user addresses coherent with each other (like parisc does), you need to
> figure out which process to be coherent with.

Having all userspace addresses of a page across all processes coherent with
each other is the only practicable solution in Linux; at least I don't think
how otherwise and within the currently kernel framework a platform could
sanely handle userspace-userspace aliases.  So we're talking about extending
this to cover userspace-kernelspace aliases.

The original reason for the introduction of kmap_coherent was avoiding
a cache alias in when a multi-threaded process forks.  The issue has been
debated on lkml in 2006 as part of my submission of a patchset under the
subject of "Fix COW D-cache aliasing on fork".  The description is somewhat
lengthy so I omit it here.

One of the ugly parts of kmap_coherent() is that it cannot be used safely
if the page has been marked as dirty by flush_dcache_page(); the callers
know about this and deal with it.

> I know James Bottomley did an experiment (and did an OLS presentation
> ...) on unmapping the entire page cache and greatly expanding the kmap
> area to do just this kind of thing.  I think he even got a speedup.

The speedup is no surprise.

  Ralf

  reply	other threads:[~2008-11-20 17:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-18 14:06 O_DIRECT patch for processors with VIPT cache for mainline kernel (specifically arm in our case) Naval Saini
2008-11-19  6:40 ` Nick Piggin
2008-11-19 20:43   ` Russell King - ARM Linux
2008-11-20  6:59     ` Nick Piggin
2008-11-20  9:19       ` Russell King - ARM Linux
2008-11-20  9:19         ` Russell King - ARM Linux
2008-11-20 10:55         ` Naval Saini
2008-11-21 17:10         ` Catalin Marinas
2008-11-20 12:28       ` Dmitry Adamushko
2008-11-20 13:25         ` Nick Piggin
2008-11-20 13:55           ` Ralf Baechle
2008-11-20 15:27             ` Matthew Wilcox
2008-11-20 17:17               ` Ralf Baechle [this message]
2008-11-20 17:40                 ` Matthew Wilcox
2008-11-20 19:30                   ` Russell King - ARM Linux
2008-11-20 19:30                     ` Russell King - ARM Linux
2008-11-20 16:30             ` Russell King - ARM Linux
2008-11-20 16:30               ` Russell King - ARM Linux
2008-11-20 13:59           ` Dmitry Adamushko

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=20081120171713.GB27398@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dmitry.adamushko@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=matthew@wil.cx \
    --cc=naval.saini@nxp.com \
    --cc=navalnovel@gmail.com \
    --cc=nickpiggin@yahoo.com.au \
    /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.