Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Benjamin Herrenschmidt
> To elaborate on this one... I realise for this one that in the kernel > where this is currently used everything is non-preemptible anyway > because of the ptl. And I also realise that -rt kernel issues don't > really have a bearing on mainline kernel.. but the generic > implementation of this AP

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Benjamin Herrenschmidt
On Mon, 2007-07-09 at 20:12 +1000, Nick Piggin wrote: > Benjamin Herrenschmidt wrote: > > On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote: > > > >>They could just #define one to the other though, there are only a > >>small > >>number of them. Is there a downside to not making them distinct? i

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Nick Piggin
Nick Piggin wrote: Benjamin Herrenschmidt wrote: On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote: They could just #define one to the other though, there are only a small number of them. Is there a downside to not making them distinct? i386 for example probably would just keep doing a tlb

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Nick Piggin
Benjamin Herrenschmidt wrote: On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote: They could just #define one to the other though, there are only a small number of them. Is there a downside to not making them distinct? i386 for example probably would just keep doing a tlb flush for fork and n

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Benjamin Herrenschmidt
On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote: > They could just #define one to the other though, there are only a > small > number of them. Is there a downside to not making them distinct? i386 > for example probably would just keep doing a tlb flush for fork and > not > want to worry about

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Nick Piggin
Benjamin Herrenschmidt wrote: On Mon, 2007-07-09 at 17:39 +1000, Nick Piggin wrote: Would it be better off to start off with a new API for this? The mmu gather I think is traditionally entirely for dealing with page removal... It would be weird because the new API would mostly duplicate thi

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Benjamin Herrenschmidt
On Mon, 2007-07-09 at 17:39 +1000, Nick Piggin wrote: > Would it be better off to start off with a new API for this? The > mmu gather I think is traditionally entirely for dealing with > page removal... It would be weird because the new API would mostly duplicate this one, and we would end up wit

Re: [RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-09 Thread Nick Piggin
Benjamin Herrenschmidt wrote: Use mmu_gather for fork() instead of flush_tlb_mm() This patch uses an mmu_gather for copying page tables instead of flush_tlb_mm(). This allows archs like ppc32 with hash table to avoid walking the page tables a second time to invalidate hash entries, and to only f

[RFC/PATCH] Use mmu_gather for fork() instead of flush_tlb_mm()

2007-07-08 Thread Benjamin Herrenschmidt
Use mmu_gather for fork() instead of flush_tlb_mm() This patch uses an mmu_gather for copying page tables instead of flush_tlb_mm(). This allows archs like ppc32 with hash table to avoid walking the page tables a second time to invalidate hash entries, and to only flush PTEs that have actually bee