Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

2007-09-04 Thread Natalie Protasevich
On 9/4/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote: > > This patch allows to disable ptc.g. The code used to be in the kernel, then > > was removed > > in 2.4 since the bug that it was fixing has gone away. However, some large >

Re: [PATCH] slub - Use local_t protection

2007-09-04 Thread Christoph Lameter
On Tue, 4 Sep 2007, Mathieu Desnoyers wrote: > @@ -1566,12 +1565,13 @@ redo: > object[c->offset]) != object)) > goto redo; > > - put_cpu(); > + local_exit(flags); > if (unlikely((gfpflags & __GFP_ZERO))) > memset(object, 0, c->objsi

[PATCH] local_t protection (critical section)

2007-09-04 Thread Mathieu Desnoyers
local_t protection (critical section) Adds local_enter(flags) and local_exit(flags) as primitives to surround critical sections using local_t types. On architectures providing fast atomic primitives, this turns into a preempt disable/enable(). However, on architectures not providing such fast pri

[PATCH] slub - Use local_t protection

2007-09-04 Thread Mathieu Desnoyers
slub - Use local_t protection Use local_enter/local_exit for protection in the fast path. Depends on the cmpxchg_local slub patch. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c | 18 ++ 1 file changed, 10 insertion

Re: [PATCH] SLUB use cmpxchg_local

2007-09-04 Thread Mathieu Desnoyers
* Christoph Lameter ([EMAIL PROTECTED]) wrote: > Measurements on IA64 slub w/per cpu vs slub w/per cpu/cmpxchg_local > emulation. Results are not good: > Hi Christoph, I tried to come up with a patch set implementing the basics of a new critical section: local_enter(flags) and local_exit(flags)

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

2007-09-04 Thread Bjorn Helgaas
On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote: > This patch allows to disable ptc.g. The code used to be in the kernel, then > was removed > in 2.4 since the bug that it was fixing has gone away. However, some large > system vendors > now want this capability available throu

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

2007-09-04 Thread Natalie Protasevich
On 03 Sep 2007 05:21:41 -0400, Jes Sorensen <[EMAIL PROTECTED]> wrote: > > "Natalie" == Natalie Protasevich <[EMAIL PROTECTED]> writes: > > Natalie> From: Natalie Protasevich <[EMAIL PROTECTED]> > > Natalie> This patch allows to disable ptc.g. The code used to be in > Natalie> the kernel, then

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

2007-09-04 Thread Natalie Protasevich
On 9/4/07, Luck, Tony <[EMAIL PROTECTED]> wrote: > >> global cache purge in their chipset implementation. (For such cases, Intel > >> provided a SAL > >> table entry to specify if ptc.g is allowed and how many). > > > > This seems odd. You never use that sal call to initialized noptcg. > > Is tha

RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

2007-09-04 Thread Luck, Tony
>> global cache purge in their chipset implementation. (For such cases, Intel >> provided a SAL >> table entry to specify if ptc.g is allowed and how many). > > This seems odd. You never use that sal call to initialized noptcg. > Is that an oversight? The mechanism is a SAL table entry, not a S

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

2007-09-04 Thread Robin Holt
Please don't take this as a review. I only glanced over it while waiting for coffee to brew. How does this align with sn2's tlb shootdown mechanism? It seems similar in intent. On Mon, Sep 03, 2007 at 01:06:20AM -0700, Natalie Protasevich wrote: > global cache purge in their chipset implementa

RE: git pull on ia64 linux tree

2007-09-04 Thread Linus Torvalds
On Sat, 1 Sep 2007, Luck, Tony wrote: > > Note to anyone else using my GIT tree ... this means my tree jumped > sideways and you won't be able to pull from it if you had done a pull > since Thursday. You'll have to back the branch you use to track my > tree back up (e.g. to v2.6.23-rc4) before