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
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
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
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
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
> >
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
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
>
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
>
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
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
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
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
Move
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
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't get an
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
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
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
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 locking /
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
22 matches
Mail list logo
