On Thu, Jul 05, 2007 at 10:57:00AM +0200, Zoltan Menyhart wrote:
> KAMEZAWA Hiroyuki wrote:
> >In our test, we confirmed that this can be fixed by flushing L2I just
> >before SetPageUptodate() in NFS.
>
> I can agree.
> We can be more permissive: it can be done anywhere after the new
> data is pu
KAMEZAWA Hiroyuki wrote:
On Wed, 04 Jul 2007 16:24:38 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
Machines star up whit bit 5 = 0, reading instruction pages via
NFS has to flush them from L2I.
In our test, we confirmed that this can be fixed by flushing L2I just before
SetPageUptodate(
On Wed, 04 Jul 2007 16:24:38 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> Machines star up whit bit 5 = 0, reading instruction pages via
> NFS has to flush them from L2I.
>
In our test, we confirmed that this can be fixed by flushing L2I just before
SetPageUptodate() in NFS.
>
> I was won
Could you please confirm that I understand correctly what is in the:
Dual-Core Update to the Intel Itanium 2 Processor Reference Manual...
"2.3.3.2 L2 Caches
...
Any coherence request to identify whether a cache line is in the processor
will invalidate that line from the L2I cache."
This makes
On Tue, May 01, 2007 at 09:43:29PM +1000, Nick Piggin wrote:
> Rohit Seth wrote:
...
> >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 vagu
Rohit Seth wrote:
On Tue, 2007-05-01 at 21:52 +1000, Nick Piggin wrote:
Rohit Seth wrote:
and
it's only interested when it's executable i.e. "lazy_mmu_prot_update"
is a name concealing some overdesign.
You are right that ia64 is only interested in whne the execute permissions
kick in (an
Rohit Seth wrote:
On Tue, 2007-05-01 at 21:39 +1000, Nick Piggin wrote:
Rohit Seth wrote:
If a user is requesting kernel to do (for example) write on a page that is
already mapped with execute and write permissions then it should be treated
as if the user space is doing modifications to tha
On Tue, 2007-05-01 at 21:47 +1000, Nick Piggin wrote:
> Rohit Seth wrote:
> >
> >
> > It is invalidating any entries (containing same physical address) in both I
> > and D caches. Any dirty lines in D cache are written back to memory before
> > getting invalidated (ofcourse).
>
> OK. (should it
On Tue, 2007-05-01 at 21:52 +1000, Nick Piggin wrote:
> Rohit Seth wrote:
>
> >>and
> >>it's only interested when it's executable i.e. "lazy_mmu_prot_update"
> >>is a name concealing some overdesign.
> >
> >
> > You are right that ia64 is only interested in whne the execute permissions
> > kick
On Tue, 2007-05-01 at 21:39 +1000, Nick Piggin wrote:
> Rohit Seth wrote:
> >
> > If a user is requesting kernel to do (for example) write on a page that is
> > already mapped with execute and write permissions then it should be treated
> > as if the user space is doing modifications to that page
Rohit Seth wrote:
and
it's only interested when it's executable i.e. "lazy_mmu_prot_update"
is a name concealing some overdesign.
You are right that ia64 is only interested in whne the execute permissions
kick in (and FWIW ia64 used to use update_mmu_cache API to do what it is now
doing lazy
] ia64: race flushing icache in do_no_page path
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, t
Rohit Seth wrote:
-Original Message-
From: Hugh Dickins [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 10:20 PM
To: Nick Piggin
Cc: [EMAIL PROTECTED]; Mike Stroyan; Andrew Morton; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race
Rohit Seth wrote:
-Original Message-
From: Nick Piggin [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 7:00 PM
To: [EMAIL PROTECTED]
Cc: Mike Stroyan; Andrew Morton; Hugh Dickins; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race
Hi Nick,
-Original Message-
From: Nick Piggin [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 11:03 PM
To: Hugh Dickins
Cc: [EMAIL PROTECTED]; Mike Stroyan; Andrew Morton; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing
Hi Hugh,
-Original Message-
From: Hugh Dickins [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 10:34 PM
To: Rohit Seth
Cc: Nick Piggin; Mike Stroyan; Andrew Morton; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing icache in
-Original Message-
From: Hugh Dickins [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 10:20 PM
To: Nick Piggin
Cc: [EMAIL PROTECTED]; Mike Stroyan; Andrew Morton; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing icache in
-Original Message-
From: Nick Piggin [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 7:00 PM
To: [EMAIL PROTECTED]
Cc: Mike Stroyan; Andrew Morton; Hugh Dickins; Luck, Tony;
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Re: Fw: [PATCH] ia64: race flushing icache in
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
On Fri, 27 Apr 2007, Rohit Seth wrote:
> On Fri, 2007-04-27 at 15:18 +0100, Hugh Dickins wrote:
>
> Right. Extra flush_icache_page routines will add cost to archs that
> have non-null definition of this routine. BTW, isn't flush_icache_page
> marked for deprecation?
Yes, flush_icache_page is ma
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:
Nick Piggin wrote:
Rohit Seth wrote:
You mean by user space? If so, then it is user space responsibility to
do the appropriate operations (like flush icache in this case).
No, I mean places that set PG_arch_1. flush_dcache_page. This can
happen for mapped pages in write, splice, install_arg
Nick Piggin wrote:
What if you were to say remove all the PG_arch_1 code, and do something
really simple like flush icache in flush_dcache_page? Would performance
suffer horribly?
OIC, you need a virtual address to evict the icache, so you can't
flush at flush_dcache time? Or does ia64 have an
Hugh Dickins wrote:
On Fri, 27 Apr 2007, Nick Piggin wrote:
But that's because of ia64's cache coherency implementation. I don't really
follow the documentation to know whether it should be one way or the other,
but surely it should be done either before or after the set_pte_at, not both.
Anyw
Rohit Seth wrote:
On Fri, 2007-04-27 at 21:55 +1000, Nick Piggin wrote:
That's the theory. However, I'd still like to know how the arch code can
make the assertion that icache is known to be at all times other than at
the time of a fault?
Kernel needs to only worry about the updates that i
On Fri, 2007-04-27 at 15:18 +0100, Hugh Dickins wrote:
> I presume Mike and Anil are correct, that it needs to be done before
> putting pte into page table, not left until after: but as you've
> guessed, that needs to be done everywhere, not just in the two
> places so far identified.
>
That soun
On Fri, 2007-04-27 at 21:55 +1000, Nick Piggin wrote:
> That's the theory. However, I'd still like to know how the arch code can
> make the assertion that icache is known to be at all times other than at
> the time of a fault?
>
Kernel needs to only worry about the updates that it does. So, if
My book has a fairly detailed discussion of how these operations were
supposed to work and what the reasoning behind them was.
Unfortunately, I don't have time to really participate this discussion
at the moment, but I hope somebody else has access to the book and
would (re-)read it for some backg
On Fri, 27 Apr 2007, Nick Piggin wrote:
>
> But that's because of ia64's cache coherency implementation. I don't really
> follow the documentation to know whether it should be one way or the other,
> but surely it should be done either before or after the set_pte_at, not both.
>
> Anyway, how abo
Mike Stroyan wrote:
On Thu, Apr 26, 2007 at 05:53:49PM +1000, Nick Piggin wrote:
I had a couple of questions which I'm hoping someone would be kind
enough to explain :)
...
I wonder how this is different to all the other code which calls
lazy_mmu_prot_update() after set_pte_at(). do_swap_pa
On Thu, Apr 26, 2007 at 05:53:49PM +1000, Nick Piggin wrote:
> I had a couple of questions which I'm hoping someone would be kind
> enough to explain :)
...
> I wonder how this is different to all the other code which calls
> lazy_mmu_prot_update() after set_pte_at(). do_swap_page, for example,
> _
Hi,
I had a couple of questions which I'm hoping someone would be kind
enough to explain :)
Andrew Morton wrote:
guys, aplication crashes on million-dollar machines aren't nice. Please review
carefully
and urgently?
Begin forwarded message:
Date: Wed, 25 Apr 2007 18:16:15 -0600
From: Mike
32 matches
Mail list logo