linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: Discontiguous memory and cacheflush
Date: Thu, 16 Aug 2012 09:27:26 +0100	[thread overview]
Message-ID: <20120816082726.GA2101@linaro.org> (raw)
In-Reply-To: <1822556972.575011.1345068509111.JavaMail.root@mozilla.com>

On Wed, Aug 15, 2012 at 03:08:29PM -0700, Martin Rosenberg wrote:
> 
> 
> ----- Original Message -----
> From: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
> To: "Jonathan Austin" <jonathan.austin@arm.com>
> Cc: "Martin Rosenberg" <mrosenberg@mozilla.com>, "Will Deacon" <will.deacon@arm.com>, linux-arm-kernel at lists.infradead.org
> Sent: Monday, August 13, 2012 9:00:08 AM
> Subject: Re: Discontiguous memory and cacheflush
> 
> 
> > It's intention is to support self-modifying userspace code only and also
> > intended to be used over a _short_ range of addresses only - it works by
> > flushing each _individual_ cache line over the range of addreses
> > requested.
> Documenting the current behavior would mostly be acceptable, but it is rather confusing (and took quite some time to track down)
> 
> > If it's going to be used for significantly larger areas, then we need to
> > think about imposing a limit, upon which we just flush the entire cache
> > and be done with it.
> 
> I found that there was still a net win making fewer syscalls, even with the overhead of flushing extra cache lines.
> In the cases where the range is discontiguous, I usually need to do something silly, like flush 20 individual instructions that are scattered throughout several hundred MB of memory.  I think the fastest method for flushing in this case would be to shave a different call, with a different api, where userspace can provide an array of addresses that need to be flushed, but that sounds like material for a new thread.  Thanks --Marty

Could we use the currently must-be-zero flags parameter to add new
functionality to this syscall, or are there legacy uses of that
parameter (or history of userspace not bothering to zero it?)

For example, we could have something like

do_cache_op(struct iovec *iov, int iovcnt, CF_IOVEC)

to flush a discontiguous set of ranges described by an iovec (though we
can of course also describe the ranges in other ways)

Cheers
---Dave

  reply	other threads:[~2012-08-16  8:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <447177957.1189939.1344577602635.JavaMail.root@mozilla.com>
2012-08-10  5:52 ` Discontiguous memory and cacheflush Martin Rosenberg
2012-08-13 14:42   ` Jonathan Austin
2012-08-13 16:00     ` Russell King - ARM Linux
2012-08-15 22:08       ` Martin Rosenberg
2012-08-16  8:27         ` Dave Martin [this message]
2012-08-16  9:19           ` Russell King - ARM Linux
2012-08-16  9:43             ` Dave Martin
2012-08-17 15:53         ` Jonathan Austin
2012-08-17 21:03           ` Russell King - ARM Linux

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=20120816082726.GA2101@linaro.org \
    --to=dave.martin@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).