On 3/21/2007, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> Thing is, such a patch would amount to adding a test-for-NULL to codepaths
> which we *know* do not need it. There is no point in doing that.
Now you're just being stubborn, Andrew ;-).
The extra check does not matter much at all for mo
On Wed, 21 March 2007 08:30:27 -0800, Andrew Morton wrote:
> On Wed, 21 Mar 2007 16:41:19 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
>
> > Yeah, I'll try to sneak a patch past Andrew.
>
> That would be sneaky.
>
> Thing is, such a patch would amount to adding a test-for-NULL to codepaths
>
On Wed, 21 Mar 2007 16:41:19 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > IMHO one way to find them is to actually slow down kmem_cache_free() and see
> > where the performance is hurt.
>
> Yeah, I'll try to sneak a patch past Andr
On Wed, Mar 21, 2007 at 03:36:34PM +0200, Pekka J Enberg wrote:
> On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> > With __kmem_cache_free you would set #1 I hope, but if
> > nobody would use this - debugging time wouldn't change.
>
> I think you got it backwards. I suggested making the _current_
On 3/21/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
IMHO one way to find them is to actually slow down kmem_cache_free() and see
where the performance is hurt.
Yeah, I'll try to sneak a patch past Andrew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wednesday, 21 March 2007 14:36, Pekka J Enberg wrote:
> On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> > With __kmem_cache_free you would set #1 I hope, but if
> > nobody would use this - debugging time wouldn't change.
>
> I think you got it backwards. I suggested making the _current_
> kmem_
On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> With __kmem_cache_free you would set #1 I hope, but if
> nobody would use this - debugging time wouldn't change.
I think you got it backwards. I suggested making the _current_
kmem_cache_free() deal with NULL (so everyone will get it) and add a new
On Wed, Mar 21, 2007 at 02:13:52PM +0200, Pekka Enberg wrote:
> On 3/21/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >I think Pekka was right (it looks he changed his mind now) something
> >should be done here. I think something like this should be a minimum:
> >
> >BUG_ON(!objp || virt_to_cach
On 3/21/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
I think Pekka was right (it looks he changed his mind now) something
should be done here. I think something like this should be a minimum:
BUG_ON(!objp || virt_to_cache(objp) != cachep);
to show distinctly what's going on.
No, if we were
On Tue, 20 Mar 2007, Christoph Lameter wrote:
> CONFIG_DEBUG_SLAB is there in order to handle these nasty and hard to
> debug problems. Usually non-slab pages are not passed to kmem_cache_free.
Yeah, it's probably not a big deal for kmem_cache_free() but if we make
the BUG_ON CONFIG_DEBUG_SLAB,
On 20-03-2007 08:47, Pekka J Enberg wrote:
> On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
...
> On Tue, 20 Mar 2007, Eric Dumazet wrote:
>> CPU: AMD64 processors, speed 1992.52 MHz (estimated)
>> Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
>> mask of 0x00 (No
On Tue, 20 Mar 2007, Pekka Enberg wrote:
> On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The BUG_ON (at least) should probably be moved into CONFIG_DEBUG_SLAB.
>
> No it shouldn't. Letting non-slab pages pass through causes nasty and
> hard to debug problems which is why we have the BU
Pekka J Enberg a écrit :
Thanks for the profile. I still wonder where exactly thouse super-hot
call-sites are...
In this case, it's a typical network server
Each time a packet is sent to or received from network, network stack has to
allocate/free a skb (kmem_cache_alloc()/kmem_cache_free()
On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > This is a super-hot path.
At some point in time, I wrote:
> > Super-hot exactly where?
On Tue, 20 Mar 2007, Eric Dumazet wrote:
> Don't be silly Pekka ... We have plenty oprofiles results if you dont trust
> Andrew.
Oh, don't get me wron
Pekka Enberg a écrit :
On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
This is a super-hot path.
Super-hot exactly where?
Don't be silly Pekka ... We have plenty oprofiles results if you dont trust
Andrew.
CPU: AMD64 processors, speed 1992.52 MHz (estimated)
Counted CPU_CLK_UNHALTED
On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
This is a super-hot path.
Super-hot exactly where?
-
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/majordomo-info.html
Plea
On 3/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
The BUG_ON (at least) should probably be moved into CONFIG_DEBUG_SLAB.
No it shouldn't. Letting non-slab pages pass through causes nasty and
hard to debug problems which is why we have the BUG_ONs in the first
place:
http://lkml.org/lkml/200
Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This changes kmem_cache_free() to deal with NULL objects passed to it. The
> current behavior is inconsistent with kfree() so there are callers
> passing NULL to kmem_cache_free().
>
> Andreas, can you please confirm this fixes
On Mon, 19 March 2007 14:10:38 -0700, Andrew Morton wrote:
>
> Would prefer to do:
>
> static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
> void *objp)
> {
> if (objp)
> kmem_cache_free(cachep, objp);
> }
>
On Mon, Mar 19, 2007 at 02:41:00PM -0700, Andrew Morton wrote:
> On Mon, 19 Mar 2007 23:25:36 +0200 (EET)
> "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
>
> >
> > On 3/19/2007, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> > > Would prefer to do:
> > >
> > > static inline void kmem_cache_free_if_not
On Mon, Mar 19, 2007 at 02:16:01PM -0700, Christoph Lameter wrote:
> On Mon, 19 Mar 2007, Matt Mackall wrote:
>
> > I think this sort of thing should work:
> >
> > a = kmalloc(...)
> > b = kmem_cache_alloc(..)
> > c = allocate_some_id(...)
> > if (!a || !b || !c) {
> >free_some_id(c)
> >k
On Mon, 19 Mar 2007 23:25:36 +0200 (EET)
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
>
> On 3/19/2007, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> > Would prefer to do:
> >
> > static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
> >
On 3/19/2007, "Andrew Morton" <[EMAIL PROTECTED]> wrote:
> Would prefer to do:
>
> static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep,
> void *objp)
> {
> if (objp)
> kmem_cache_free(cachep, objp);
> }
>
> so
On Mon, 19 Mar 2007, Matt Mackall wrote:
> I think this sort of thing should work:
>
> a = kmalloc(...)
> b = kmem_cache_alloc(..)
> c = allocate_some_id(...)
> if (!a || !b || !c) {
>free_some_id(c)
>kmem_cache_free(c)
this requires the specification of a kmem_cache structure and t
On Mon, 19 Mar 2007 15:49:46 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 19, 2007 at 10:08:03AM -0700, Christoph Lameter wrote:
> > On Mon, 19 Mar 2007, Pekka J Enberg wrote:
> >
> > > This changes kmem_cache_free() to deal with NULL objects passed to it.
> > > The
> > > current
On Mon, Mar 19, 2007 at 10:08:03AM -0700, Christoph Lameter wrote:
> On Mon, 19 Mar 2007, Pekka J Enberg wrote:
>
> > This changes kmem_cache_free() to deal with NULL objects passed to it. The
> > current behavior is inconsistent with kfree() so there are callers
> > passing NULL to kmem_cache_f
On Mon, 19 Mar 2007, Christoph Lameter wrote:
> Hmmm.. kmem_cache_free is significantly different. One also needs to
> specify the slab cache.
No, it really isn't. Why would we want kfree() to be special? It's only
going to confuse people which results in bugs.
On Mon, 19 Mar 2007, Christoph La
On Mon, 19 Mar 2007, Pekka J Enberg wrote:
> This changes kmem_cache_free() to deal with NULL objects passed to it. The
> current behavior is inconsistent with kfree() so there are callers
> passing NULL to kmem_cache_free().
Hmmm.. kmem_cache_free is significantly different. One also needs to
Hi,
On Mon, 19 Mar 2007, Andrew Morton wrote:
> err, we don't want to do this, do we? It adds overhead for something which
> we've carefully taught all our programmers to not do. The only known code
> which will benefit from this is buggy.
Well, I actually disagree with that. It makes little se
On Mon, 19 Mar 2007 10:27:18 +0200 (EET) Pekka J Enberg <[EMAIL PROTECTED]>
wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This changes kmem_cache_free() to deal with NULL objects passed to it. The
> current behavior is inconsistent with kfree() so there are callers
> passing NULL to kmem
From: Pekka Enberg <[EMAIL PROTECTED]>
This changes kmem_cache_free() to deal with NULL objects passed to it. The
current behavior is inconsistent with kfree() so there are callers
passing NULL to kmem_cache_free().
Andreas, can you please confirm this fixes the oops you reported on
linux-scsi
31 matches
Mail list logo
