On Tue, 6 Nov 2007, Jeff Chua wrote:
> On Nov 6, 2007 2:45 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > 1. We can avoid going back to the page allocator for awhile since we will
> > find the almost free slab if the current slab is exhausted.
>
> Does this impact SLAB as well?
No, it's
On Nov 6, 2007 2:45 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 1. We can avoid going back to the page allocator for awhile since we will
> find the almost free slab if the current slab is exhausted.
Does this impact SLAB as well? I'm getting out of memory with kernel
2.6.21, 2.6.22 and 2.
On Mon, 5 Nov 2007, Christoph Lameter wrote:
>
> > Will you send the equivalent one for the current -git tree?
>
> I already sent that on Saturday (also sent a version against mm which is
> a bit different now).
With all the back-and-forth with you and Hugh, I wanted to make sure I
knew what
On Mon, 5 Nov 2007, Linus Torvalds wrote:
> > Here is the fix against 2.6.23:
>
> Will you send the equivalent one for the current -git tree?
I already sent that on Saturday (also sent a version against mm which is
a bit different now). Here is the version against git again:
SLUB: Fix memory
On Mon, 5 Nov 2007, Christoph Lameter wrote:
>
> Here is the fix against 2.6.23:
Will you send the equivalent one for the current -git tree?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
Fix against 2.6.22 (the .23 fix also applies with some offsets)
SLUB: Fix memory leak by not reusing cpu_slab
Fix the memory leak that may occur when we attempt to reuse a cpu_slab
that was allocated while we reenabled interrupts in order to be able to
grow a slab cache. The per cpu freelist may
On Mon, 5 Nov 2007, Hugh Dickins wrote:
> Okay, I wanted to make the point, but I've no wish to hold up your fix
> (and removing code, particularly code that has given trouble, is always
> welcome). Please go ahead - thanks.
Here is the fix against 2.6.23:
SLUB: Fix memory leak by not reusing c
On Mon, 5 Nov 2007, Christoph Lameter wrote:
> On Sun, 4 Nov 2007, Hugh Dickins wrote:
>
> > In a low memory situation, when several tasks pile up to allocate
> > the same resource, we'd usually free back all but the first, rather
> > than depleting free memory even more than necessary. That you
On Sun, 4 Nov 2007, Hugh Dickins wrote:
> That testing went fine, as you'd expect. Your diffstat is certainly
> nicer than mine (corrected for SlabDebug) would be. I expect you'll
> go ahead with yours.
Thanks for testing.
> But I remain slightly uneasy about it: I do think your original
> ins
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > Neither of us has yet posted a correct patch which applies to 2.6.23
> > and 2.6.22. I'm testing your 2.6.24-rc patch overnight, and if that's
> > fine then one of us will post the version for -stable. I
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Neither of us has yet posted a correct patch which applies to 2.6.23
> and 2.6.22. I'm testing your 2.6.24-rc patch overnight, and if that's
> fine then one of us will post the version for -stable. I thought I'd
> better leave that to you, after I've rep
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > >
> > > > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > > > So stable should ignor
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> >
> > > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > > So stable should ignore my patch, and he will come up with another.
> >
> > H
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > So stable should ignore my patch, and he will come up with another.
>
> Hmmm? I thought you wanted to test the patch provided?
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Later Christoph noticed that I'm not handling the SlabDebug case right.
> So stable should ignore my patch, and he will come up with another.
Hmmm? I thought you wanted to test the patch provided?
-
To unsubscribe from this list: send the line "unsubscri
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Olivér Pintér wrote:
> > > Q: It's needed auch to 2.6.22-stable?
>
> Okay, here's a version for 2.6.23 and 2.6.22...
> Christoph, you've now Acked the 2.6.24 one, thanks:
> do you agree this p
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > >
> > > > Which fixes the leakage: Objects and Partials then remain stable.
> > >
> > > Well this code is just
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> >
> > > Which fixes the leakage: Objects and Partials then remain stable.
> >
> > Well this code is just an optimization for a rare case.
> > Your patch may not ha
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > Which fixes the leakage: Objects and Partials then remain stable.
>
> Well this code is just an optimization for a rare case.
> Your patch may not handle the debug situation the right way.
Oh? How?
> W
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Olivér Pintér wrote:
> > Q: It's needed auch to 2.6.22-stable?
>
> I guess so: though SLUB wasn't on by default in 2.6.22; and it being
> only a slow leak rather than a corruption, I was less inclined to
> agitate about it for releases
The fix against mm:
SLUB: Fix memory leak by not reusing cpu_slab
Fix the memory leak that may occur when we attempt to reuse a cpu_slab
that was allocated while we reenabled interrupts in order to be able to
grow a slab cache. The per cpu freelist may contain objects and in that
situation we ma
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Which fixes the leakage: Objects and Partials then remain stable.
Well this code is just an optimization for a rare case. Your patch may not
handle the debug situation the right way. We could just remove it.
SLUB: Fix memory leak by not reusing cpu_sl
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> The culprit turns out to be __slab_alloc(), where it copes with the race
> that another task has assigned the cpu slab while we were allocating one.
> Don't rush off to load_freelist there: that assumes c->freelist is empty,
> and will lose all of its free
On Sat, Nov 03, 2007 at 05:55:50PM +, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Willy Tarreau wrote:
> > On Sat, Nov 03, 2007 at 05:10:54PM +, Hugh Dickins wrote:
> > > I recommend this for 2.6.24-rc2 and 2.6.23-stable.
> >
> > Hugh, you should also have CC'd linux-stable for this, otherwi
On Sat, 3 Nov 2007, Willy Tarreau wrote:
> On Sat, Nov 03, 2007 at 05:10:54PM +, Hugh Dickins wrote:
> > I recommend this for 2.6.24-rc2 and 2.6.23-stable.
>
> Hugh, you should also have CC'd linux-stable for this, otherwise there's
> a risk that the patch remains unnoticed by the stable team
On Sat, 3 Nov 2007, Olivér Pintér wrote:
> Q: It's needed auch to 2.6.22-stable?
I guess so: though SLUB wasn't on by default in 2.6.22; and it being
only a slow leak rather than a corruption, I was less inclined to
agitate about it for releases further back.
But your question makes me realize I
On Sat, Nov 03, 2007 at 05:10:54PM +, Hugh Dickins wrote:
> Slub has been quite leaky under load. Taking mm_struct as an example, in
> a loop of swapping kernel builds, after the first iteration slabinfo shows:
> NameObjects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg
> mm_struc
Q: It's needed auch to 2.6.22-stable?
On 11/3/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> Slub has been quite leaky under load. Taking mm_struct as an example, in
> a loop of swapping kernel builds, after the first iteration slabinfo shows:
> NameObjects ObjsizeSpace Slabs/Part/Cpu
Slub has been quite leaky under load. Taking mm_struct as an example, in
a loop of swapping kernel builds, after the first iteration slabinfo shows:
NameObjects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg
mm_struct55 84073.7K 18/7/44 0 38 62 A
but Objec
29 matches
Mail list logo
