All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Tomlinson <tomlins@cam.org>
To: Andrew Morton <akpm@digeo.com>,
	John Levon <movement@marcelothewonderpenguin.com>,
	Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.39 kmem_cache bug
Date: Sun, 29 Sep 2002 07:45:20 -0400	[thread overview]
Message-ID: <200209290745.20484.tomlins@cam.org> (raw)
In-Reply-To: <3D961797.B4094994@digeo.com>

On September 28, 2002 04:56 pm, Andrew Morton wrote:
> John Levon wrote:
> > kmem_cache_destroy() is falsely reporting
> > "kmem_cache_destroy: Can't free all objects" in 2.5.39. I have
> > verified my code was freeing all allocated items correctly.
> >
> > Reverting this chunk :
> >
> > -                       list_add(&slabp->list, &cachep->slabs_free);
> > +/*                     list_add(&slabp->list, &cachep->slabs_free);     
> >       */ +                       if
> > (unlikely(list_empty(&cachep->slabs_partial))) +                         
> >      list_add(&slabp->list, &cachep->slabs_partial); +                   
> >    else
> > +                               kmem_slab_destroy(cachep, slabp);
> >
> > and the problem goes away. I haven't investigated why.
>kmem_cache_destroy
> Thanks.  That's the code which leaves one empty page available
> for new allocations rather than freeing it immediately.
>
> It's temporary.  Ed, I think we can just do
>
> 	if (list_empty(&cachep->slabs_free))
> 		list_add(&slabp->list, &cachep->slabs_free);
> 	else
> 		kmem_slab_destroy(cachep, slabp);
>
> there?

Yes we can do this.  I would rather fix kmem_cache_destroy though.  Think that, if 
we play our cards right, we can get rid of the cachep->slabs_free list with out too
much pain.

Ed


  parent reply	other threads:[~2002-09-29 11:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-28 20:13 2.5.39 kmem_cache bug John Levon
2002-09-28 20:56 ` Andrew Morton
2002-09-28 21:12   ` Manfred Spraul
2002-09-28 21:23   ` John Levon
2002-09-28 21:35     ` Andrew Morton
2002-09-29 11:45   ` Ed Tomlinson [this message]
2002-09-29 12:13     ` Manfred Spraul
2002-09-29 13:15   ` Ed Tomlinson
2002-09-29 13:52     ` Manfred Spraul
2002-09-29 13:53     ` John Levon
     [not found] ` <200209291137.48483.tomlins@cam.org>
     [not found]   ` <3D972828.6010807@colorfullife.com>
2002-09-30  0:20     ` Ed Tomlinson
2002-09-30  5:55       ` Manfred Spraul
2002-09-30 11:18         ` Ed Tomlinson
2002-09-30 16:33           ` Manfred Spraul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200209290745.20484.tomlins@cam.org \
    --to=tomlins@cam.org \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=movement@marcelothewonderpenguin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.