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 invalid
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
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 s
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
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
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 in
in do_no_page path
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 mappe
in do_no_page path
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
-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
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, 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
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
to be incremented in
NODE_MIN_SIZE granule and uniformly distribute among as many nodes
(called big nodes) as possible.
Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
Signed-off-by: Rohit Seth <[EMAIL PROTECTED]>
--- linux-2.6.20-rc1-m
to be incremented in
NODE_MIN_SIZE granule and uniformly distribute among as many nodes
(called big nodes) as possible.
Signed-off-by: David Rientjes [EMAIL PROTECTED]
Signed-off-by: Paul Menage [EMAIL PROTECTED]
Signed-off-by: Rohit Seth [EMAIL PROTECTED]
--- linux-2.6.20-rc1-mm1.org/include/asm
On Tue, 2006-11-28 at 21:34 +, Mel Gorman wrote:
> On Tue, 28 Nov 2006, Rohit Seth wrote:
>
> > On Tue, 2006-11-28 at 13:24 +, Mel Gorman wrote:
> >> On Mon, 27 Nov 2006, Rohit Seth wrote:
> >>
> >>> Hi Mel,
> >>>
> >>>
On Tue, 2006-11-28 at 13:24 +, Mel Gorman wrote:
> On Mon, 27 Nov 2006, Rohit Seth wrote:
>
> > Hi Mel,
> >
> > On Mon, 2006-11-27 at 13:18 +, Mel Gorman wrote:
> >> On Wed, 22 Nov 2006, Rohit Seth wrote:
> >>
> >>> This
On Tue, 2006-11-28 at 13:24 +, Mel Gorman wrote:
On Mon, 27 Nov 2006, Rohit Seth wrote:
Hi Mel,
On Mon, 2006-11-27 at 13:18 +, Mel Gorman wrote:
On Wed, 22 Nov 2006, Rohit Seth wrote:
This patch provides a IO hole size in a given address range.
Hi,
This patch
On Tue, 2006-11-28 at 21:34 +, Mel Gorman wrote:
On Tue, 28 Nov 2006, Rohit Seth wrote:
On Tue, 2006-11-28 at 13:24 +, Mel Gorman wrote:
On Mon, 27 Nov 2006, Rohit Seth wrote:
Hi Mel,
On Mon, 2006-11-27 at 13:18 +, Mel Gorman wrote:
On Wed, 22 Nov 2006, Rohit Seth
Hi Mel,
On Mon, 2006-11-27 at 13:18 +, Mel Gorman wrote:
> On Wed, 22 Nov 2006, Rohit Seth wrote:
>
> > This patch provides a IO hole size in a given address range.
> >
>
> Hi,
>
> This patch reintroduces a function that doubles up what
> absent_page
On Thu, 2006-11-23 at 10:04 +0100, Andi Kleen wrote:
> On Wed, Nov 22, 2006 at 05:34:47PM -0800, Rohit Seth wrote:
> > Fix the existing numa=fake so that ioholes are appropriately configured.
> > Currently machines that have sizeable IO holes don't work with
> > numa=fake
On Thu, 2006-11-23 at 10:04 +0100, Andi Kleen wrote:
On Wed, Nov 22, 2006 at 05:34:47PM -0800, Rohit Seth wrote:
Fix the existing numa=fake so that ioholes are appropriately configured.
Currently machines that have sizeable IO holes don't work with
numa=fake4. This patch tries to equally
Hi Mel,
On Mon, 2006-11-27 at 13:18 +, Mel Gorman wrote:
On Wed, 22 Nov 2006, Rohit Seth wrote:
This patch provides a IO hole size in a given address range.
Hi,
This patch reintroduces a function that doubles up what
absent_pages_in_range(start_pfn, end_pfn). I recognise you
28 matches
Mail list logo
