All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rohit Seth <rohitseth@google.com>
Cc: 'Hugh Dickins' <hugh@veritas.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: Tue, 01 May 2007 11:43:29 +0000	[thread overview]
Message-ID: <463727E1.3090203@yahoo.com.au> (raw)
In-Reply-To: <200704281805.l3SI5JQx030827@smtp.corp.google.com>

Rohit Seth wrote:
>  
> 
> -----Original Message-----
> From: Hugh Dickins [mailto:hugh@veritas.com] 
> Sent: Friday, April 27, 2007 10:20 PM
> To: Nick Piggin
> Cc: rohitseth@google.com; Mike Stroyan; Andrew Morton; Luck, Tony;
> linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path
> 
> 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).
> 
> 
> IIRC, there is a PAL call to flush the whole cache (but that is quite a
> heavy call).  Though you really don't need to be doing this.
> 
> 
>>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.
> 
> 
> Caches on Itanium are physical.  So, it doesn't matter what virtual address
> you use to flush a cache line, cache line containing specific physical
> memory will be flushed. 

Really? I was under the vague impression that L1 i/d caches were virtual
and required this flushing... but I guess so long as the ISA says that
fc/fc.i flushes all caches corresponding to the physical address of the
provided virtual address, then that's what matters.

> For the cases where you have virtual caches,
> update_mmu_cache is the API to use.

But it happens after the pte is installed.

-- 
SUSE Labs, Novell Inc.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rohit Seth <rohitseth@google.com>
Cc: "'Hugh Dickins'" <hugh@veritas.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: Tue, 01 May 2007 21:43:29 +1000	[thread overview]
Message-ID: <463727E1.3090203@yahoo.com.au> (raw)
In-Reply-To: <200704281805.l3SI5JQx030827@smtp.corp.google.com>

Rohit Seth wrote:
>  
> 
> -----Original Message-----
> From: Hugh Dickins [mailto:hugh@veritas.com] 
> Sent: Friday, April 27, 2007 10:20 PM
> To: Nick Piggin
> Cc: rohitseth@google.com; Mike Stroyan; Andrew Morton; Luck, Tony;
> linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path
> 
> 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).
> 
> 
> IIRC, there is a PAL call to flush the whole cache (but that is quite a
> heavy call).  Though you really don't need to be doing this.
> 
> 
>>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.
> 
> 
> Caches on Itanium are physical.  So, it doesn't matter what virtual address
> you use to flush a cache line, cache line containing specific physical
> memory will be flushed. 

Really? I was under the vague impression that L1 i/d caches were virtual
and required this flushing... but I guess so long as the ISA says that
fc/fc.i flushes all caches corresponding to the physical address of the
provided virtual address, then that's what matters.

> For the cases where you have virtual caches,
> update_mmu_cache is the API to use.

But it happens after the pte is installed.

-- 
SUSE Labs, Novell Inc.

  reply	other threads:[~2007-05-01 11:43 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 [this message]
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
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=463727E1.3090203@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.