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
>
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
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
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
* 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)
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
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
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
>> 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
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
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
11 matches
Mail list logo