All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Hugh Dickins <hugh@veritas.com>
Cc: rohitseth@google.com, Mike Stroyan <mike.stroyan@hp.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path
Date: Sat, 28 Apr 2007 06:03:28 +0000	[thread overview]
Message-ID: <4632E3B0.6050101@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0704280616470.9554@blonde.wat.veritas.com>

Hugh Dickins wrote:
> On Sat, 28 Apr 2007, Nick Piggin wrote:
> 
>>OIC, you need a virtual address to evict the icache, so you can't
>>flush at flush_dcache time? Or does ia64 have an instruction to
>>flush the whole icache? (it would be worth testing, to see how much
>>performance suffers).
> 
> 
> I'm puzzled by that remark: the ia64 flush_icache_range always has
> a virtual address, it uses the kernel virtual address; it takes no
> interest in whether there's a user virtual address.

I _think_ what it is doing is actually flushing dcache lines dirtied
via the kernel virtual address (yes, I think flush_icache in
lazy_mmu_prot_update is actually just flushing the dcache, but I could
be wrong? [*]). There are supposedly no icache lines at that point[**]:
the bug fix at the start of this thread is due to icache lines
becoming present before the flush.

[*] and if I'm right, that means that icache fills don't see dirty
dcache, but rather always load from memory? I hope someone can
answer these questions?

[**] except due to _existing_ executable mappings, of course, but they
seem to have been comprehensively disregarded...

-- 
SUSE Labs, Novell Inc.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Hugh Dickins <hugh@veritas.com>
Cc: rohitseth@google.com, Mike Stroyan <mike.stroyan@hp.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path
Date: Sat, 28 Apr 2007 16:03:28 +1000	[thread overview]
Message-ID: <4632E3B0.6050101@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0704280616470.9554@blonde.wat.veritas.com>

Hugh Dickins wrote:
> On Sat, 28 Apr 2007, Nick Piggin wrote:
> 
>>OIC, you need a virtual address to evict the icache, so you can't
>>flush at flush_dcache time? Or does ia64 have an instruction to
>>flush the whole icache? (it would be worth testing, to see how much
>>performance suffers).
> 
> 
> I'm puzzled by that remark: the ia64 flush_icache_range always has
> a virtual address, it uses the kernel virtual address; it takes no
> interest in whether there's a user virtual address.

I _think_ what it is doing is actually flushing dcache lines dirtied
via the kernel virtual address (yes, I think flush_icache in
lazy_mmu_prot_update is actually just flushing the dcache, but I could
be wrong? [*]). There are supposedly no icache lines at that point[**]:
the bug fix at the start of this thread is due to icache lines
becoming present before the flush.

[*] and if I'm right, that means that icache fills don't see dirty
dcache, but rather always load from memory? I hope someone can
answer these questions?

[**] except due to _existing_ executable mappings, of course, but they
seem to have been comprehensively disregarded...

-- 
SUSE Labs, Novell Inc.

  reply	other threads:[~2007-04-28  6:03 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070425205548.fd51b301.akpm@linux-foundation.org>
2007-04-26  7:53 ` Fw: [PATCH] ia64: race flushing icache in do_no_page path Nick Piggin
2007-04-26  7:53   ` Nick Piggin
2007-04-26 17:35   ` Mike Stroyan
2007-04-26 17:35     ` Mike Stroyan
2007-04-27 11:55     ` Nick Piggin
2007-04-27 11:55       ` Nick Piggin
2007-04-27 14:18       ` Hugh Dickins
2007-04-27 14:18         ` Hugh Dickins
2007-04-27 17:02         ` David Mosberger-Tang
2007-04-27 17:02           ` David Mosberger-Tang
2007-04-28  1:31         ` Rohit Seth
2007-04-28  1:31           ` Rohit Seth
2007-04-28  5:34           ` Hugh Dickins
2007-04-28  5:34             ` Hugh Dickins
2007-04-28  2:16         ` Nick Piggin
2007-04-28  2:16           ` Nick Piggin
2007-04-28  1:24       ` Rohit Seth
2007-04-28  1:24         ` Rohit Seth
2007-04-28  2:00         ` Nick Piggin
2007-04-28  2:00           ` Nick Piggin
2007-04-26  0:16           ` Mike Stroyan
2007-04-26  0:16             ` Mike Stroyan
2007-04-28 17:57             ` Fw: " Rohit Seth
2007-04-28 17:57               ` Rohit Seth
2007-05-01 11:39               ` Nick Piggin
2007-05-01 11:39                 ` Nick Piggin
2007-05-02  0:36                 ` Rohit Seth
2007-05-02  0:36                   ` Rohit Seth
2007-05-02  1:57                   ` Nick Piggin
2007-05-02  1:57                     ` Nick Piggin
2007-04-28 18:05             ` Rohit Seth
2007-04-28 18:05               ` Rohit Seth
2007-05-01 11:43               ` Nick Piggin
2007-05-01 11:43                 ` Nick Piggin
2007-05-04 21:32                 ` Mike Stroyan
2007-05-04 21:32                   ` Mike Stroyan
2007-04-28 18:17             ` Rohit Seth
2007-04-28 18:17               ` Rohit Seth
2007-05-01 11:52               ` Nick Piggin
2007-05-01 11:52                 ` Nick Piggin
2007-05-02  0:36                 ` Rohit Seth
2007-05-02  0:36                   ` Rohit Seth
2007-05-02  2:05                   ` Nick Piggin
2007-05-02  2:05                     ` Nick Piggin
2007-04-28 18:30             ` Rohit Seth
2007-04-28 18:30               ` Rohit Seth
2007-05-01 11:47               ` Nick Piggin
2007-05-01 11:47                 ` Nick Piggin
2007-05-02  0:36                 ` Rohit Seth
2007-05-02  0:36                   ` Rohit Seth
2007-07-04 14:24             ` Zoltan Menyhart
2007-07-04 14:24               ` Zoltan Menyhart
2007-07-04 16:58               ` KAMEZAWA Hiroyuki
2007-07-04 16:58                 ` KAMEZAWA Hiroyuki
2007-07-05  8:57                 ` Zoltan Menyhart
2007-07-05  8:57                   ` Zoltan Menyhart
2007-07-05 17:36                   ` Mike Stroyan
2007-07-05 17:36                     ` Mike Stroyan
2007-04-28  3:04           ` Nick Piggin
2007-04-28  3:04             ` Nick Piggin
2007-04-28  5:20             ` Hugh Dickins
2007-04-28  5:20               ` Hugh Dickins
2007-04-28  6:03               ` Nick Piggin [this message]
2007-04-28  6:03                 ` Nick Piggin
2007-04-28  4:11           ` Nick Piggin
2007-04-28  4:11             ` Nick Piggin

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=4632E3B0.6050101@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.stroyan@hp.com \
    --cc=rohitseth@google.com \
    --cc=tony.luck@intel.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 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.