[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0802041629290.5057@schroedinger.engr.sgi.com>
Date: Mon, 4 Feb 2008 16:32:50 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Nick Piggin <nickpiggin@...oo.com.au>
cc: willy@...ux.intel.com, Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [git pull] SLUB updates for 2.6.25
On Tue, 5 Feb 2008, Nick Piggin wrote:
> Ok. But the approach is just not so good. If you _really_ need something
> like that and it is a win over the regular non-atomic unlock, then you
> just have to implement it as a generic locking / atomic operation and
> allow all architectures to implement the optimal (and correct) memory
> barriers.
Assuming this really gives a benefit on several benchmarks then we need
to think about how to do this some more. Its a rather strange form of
locking.
Basically you lock the page with a single atomic operation that sets
PageLocked and retrieves the page flags. Then we shovel the page state
around a couple of functions in a register and finally store the page
state back which at the same time unlocks the page. So two memory
references with one of them being atomic with none in between. We have
nothing that can do something like that right now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists