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
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
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 put in
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
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
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 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 wondering
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
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 vague
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
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
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
> >
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
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
] 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, to see
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
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
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
] 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, to see
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
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 (and FWIW ia64
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. There
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 be issuing
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
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 (and
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
-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
-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
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
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
-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
-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
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
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
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
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
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,
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
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.
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
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
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
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
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().
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().
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 about
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
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
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 sounds
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
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.
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
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,
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
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 marked
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
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
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,
64 matches
Mail list logo
