mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Richard Henderson <rth@twiddle.net>,
	David Mosberger <davidm@hpl.hp.com>,
	torvalds@transmeta.com, linux-kernel@vger.kernel.org,
	davem@redhat.com
Subject: Re: [PATCH] avoid unnecessary cache flushes
Date: Tue, 4 Sep 2001 14:08:18 +1000 (EST)	[thread overview]
Message-ID: <15252.21426.787059.469270@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20010904043151.H699@athlon.random>
In-Reply-To: <15247.29338.3671.548678@cargo.ozlabs.ibm.com> <20010903131436.A16069@twiddle.net> <15251.59286.154267.431231@napali.hpl.hp.com> <20010903134125.B16069@twiddle.net> <15252.13330.652765.959658@cargo.ozlabs.ibm.com> <20010904043151.H699@athlon.random>

Andrea Arcangeli writes:

> On Tue, Sep 04, 2001 at 11:53:22AM +1000, Paul Mackerras wrote:
> > For alpha, the thing that my patch does that might hurt is the change
> > from flush_icache_page to flush_icache_range in kernel/ptrace.c.  Any
> > comment on that?
> 
> For the alpha such change will imply a performance penablity (will throw
> away the whole icache, not only the one belonging to the ptraced task).

OK then maybe we need a flush_icache_user_range or something.

> We cannot change flush_icache_range to bump the asn because there's no
> vma in the flush_icache_range API (flush_icache_range in short is for
> the kernel side, like with vmalloc and kernel modules where a
> vma/mm/tsk wouldn't make sense anyways).

Yes, that is what Documentation/cachetlb.txt says.  I note that
currently flush_icache_range is used on user addresses in
binfmt_aout.c, and in fs/binfmt_elf.c in the load_aout_interp()
function.  But nobody uses a.out these days so that doesn't matter. :)

> what's the point of such change? The whole point of the patch is to work

flush_icache_page is not a good function to use because it is called
in do_swap_page and in do_no_page in mm/memory.c and in those cases
the page might already be i-cache clean and so we don't want to do any
flush.  In those cases, if the page does actually get read in from
disk then we do want to do the flush, if it was in the page cache or
swap cache and has been flushed before then we don't want to do the
flush.  (Actually doesn't that mean that on alpha you are throwing
away the whole icache for the process every time it faults in an
executable page?)

flush_icache_page is also not a good choice because it is overkill to
flush a whole page when you have just written one word, to put in a
breakpoint or something.

> with pages not with virtual addresses so you can do the bitflag
> bookeeping on the page structure, so I don't see why would you want to
> do the opposite change there.

I would be happy with an interface that took a struct page *, and
preferably an offset and length within the page.  That would be a new
interface though.  Note that the caller of access_process_vm can't
easily do the flush without duplicating most of the logic of
access_process_vm.

Paul.

  parent reply	other threads:[~2001-09-04  4:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-31 11:18 Paul Mackerras
2001-08-31 22:45 ` David S. Miller
2001-09-01  8:55   ` David S. Miller
2001-09-01 12:24     ` David S. Miller
2001-09-01  8:35 ` Paul Mackerras
2001-09-01 11:47   ` Paul Mackerras
2001-09-03 20:14 ` Richard Henderson
2001-09-03 20:27 ` David Mosberger
2001-09-03 20:41   ` Richard Henderson
2001-09-03 21:00   ` David Mosberger
2001-09-04 16:37     ` Richard Henderson
2001-09-04 17:06     ` David Mosberger
2001-09-04  1:53   ` Paul Mackerras
2001-09-04  2:31     ` Andrea Arcangeli
2001-09-04  4:08     ` Paul Mackerras [this message]
2001-09-04 12:58       ` Andrea Arcangeli
2001-09-04 16:44     ` Richard Henderson

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=15252.21426.787059.469270@cargo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=andrea@suse.de \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rth@twiddle.net \
    --cc=torvalds@transmeta.com \
    /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

all inboxes | Powered by JetHome®