On Tue, 5 Feb 2008, Nick Piggin wrote:
> Anyway, not saying the operations are useless, but they should be
> made available to core kernel and implemented per-arch. (if they are
> found to be useful)
The problem is to establish the usefulness. These measures may bring 1-2%
in a pretty unstable o
On Tuesday 05 February 2008 11:32, Christoph Lameter wrote:
> 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 loc
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
On Tue, 5 Feb 2008, Nick Piggin wrote:
> I'm sure it could have an effect. But why is the common case in SLUB
> for the cacheline to be bouncing? What's the benchmark? What does SLAB
> do in that benchmark, is it faster than SLUB there? What does the
> non-atomic bit unlock do to Willy's database
On Tuesday 05 February 2008 10:47, Christoph Lameter wrote:
> On Tue, 5 Feb 2008, Nick Piggin wrote:
> > > erk, sorry, I misremembered. I was about to merge all the patches we
> > > weren't going to merge. oops.
> >
> > While you're there, can you drop the patch(es?) I commented on
> > and didn'
On Tue, 5 Feb 2008, Nick Piggin wrote:
> > erk, sorry, I misremembered. I was about to merge all the patches we
> > weren't going to merge. oops.
>
> While you're there, can you drop the patch(es?) I commented on
> and didn't get an answer to. Like the ones that open code their
> own locking p
On Tuesday 05 February 2008 09:30, Andrew Morton wrote:
> On Mon, 4 Feb 2008 14:28:45 -0800
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > root (1):
> > > SLUB: Do not upset lockdep
> >
> > err, what? I though I was going to merge these:
> >
> > slub-move-count_partial.patch
> > slub-ren
Hope to have the slub-mm repository setup tonight which will simplify
things for the future. Hope you still remember
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordo
On Mon, 4 Feb 2008 14:28:45 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > root (1):
> > SLUB: Do not upset lockdep
> >
>
> err, what? I though I was going to merge these:
>
> slub-move-count_partial.patch
> slub-rename-numa-defrag_ratio-to-remote_node_defrag_ratio.patch
> slub-conso
On Mon, 4 Feb 2008 12:08:34 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Updates for slub are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus
>
> Christoph Lameter (5):
> SLUB: Fix sysfs refcounting
> M
Updates for slub are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus
Christoph Lameter (5):
SLUB: Fix sysfs refcounting
Move count_partial before kmem_cache_shrink
SLUB: rename defrag to remote_node_defrag_ratio
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/christoph/slab.git to-linus
Peter Zijlstra (2):
slub: add lock debugging check
slub: fix bug in slub debug support
mm/slub.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
-
To unsubscribe from this list: sen
12 matches
Mail list logo
