On Sun, 15 Feb 2009, Matt Mackall wrote:
On Sun, 2009-02-15 at 17:00 -0800, Andrew Morton wrote:
On Sun, 15 Feb 2009 17:49:41 -0600 Matt Mackall m...@selenic.com wrote:
The whole concept is quite hacky and nasty, isn't it?.
It is, which is part of why we were trying to kill it. The
On Sun, 15 Feb 2009, Matt Mackall wrote:
And it -is- a category error. The fact that kmalloc is implemented on
top of kmem_cache_alloc is an implementation detail that callers should
not assume. They shouldn't call kfree() on kmem_cache_alloc objects
(even though it might just happen to
On Tue, Feb 17, 2009 at 6:17 PM, Christoph Lameter
c...@linux-foundation.org wrote:
On Sun, 15 Feb 2009, Matt Mackall wrote:
And it -is- a category error. The fact that kmalloc is implemented on
top of kmem_cache_alloc is an implementation detail that callers should
not assume. They shouldn't
On Tue, 17 Feb 2009, Pekka Enberg wrote:
Hmm, kmem_cache_size() seems bit pointless to me. For
kmem_cache_create()'d caches, actual allocated size should be more or
less optimal with no extra space.
Cacheline alignment and word alignment etc etc can still add some space to
the object.
--
To
On Mon, 2009-02-16 at 14:56 +0100, Johannes Weiner wrote:
One problem is that zeroing ksize()
bytes can have an overhead of nearly twice the actual allocation size.
A possible good thing is when linux has a
mechanism to use known zeroed memory in
kzalloc or kcalloc, it's already good to go.
--
On Mon, 2009-02-16 at 14:56 +0100, Johannes Weiner wrote:
One problem is that zeroing ksize()
bytes can have an overhead of nearly twice the actual allocation size.
On Mon, Feb 16, 2009 at 6:32 PM, Joe Perches j...@perches.com wrote:
A possible good thing is when linux has a
mechanism to use
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi wrote:
On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote:
Because the API was being widely abused in the nommu code, for example.
I'd rather not add it back for this special case which can be handled
On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote:
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi
wrote:
On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote:
Because the API was being widely abused in the nommu code, for example.
I'd rather
On Sun, 15 Feb 2009 15:43:14 -0600 Matt Mackall m...@selenic.com wrote:
On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote:
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi
wrote:
On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote:
On Sun, 2009-02-15 at 13:55 -0800, Andrew Morton wrote:
On Sun, 15 Feb 2009 15:43:14 -0600 Matt Mackall m...@selenic.com wrote:
On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote:
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi
wrote:
On Thu, Feb 12,
On Sun, Feb 15, 2009 at 05:00:52PM -0800, Andrew Morton wrote:
But kmem_cache_size() would tell you how much extra secret memory there
is available after the object?
How that gets along with redzoning is a bit of a mystery though.
The whole concept is quite hacky and nasty, isn't it?.
On Mon, 2009-02-16 at 09:21 +0800, Herbert Xu wrote:
On Sun, Feb 15, 2009 at 05:00:52PM -0800, Andrew Morton wrote:
But kmem_cache_size() would tell you how much extra secret memory there
is available after the object?
How that gets along with redzoning is a bit of a mystery though.
On Sun, 2009-02-15 at 17:00 -0800, Andrew Morton wrote:
On Sun, 15 Feb 2009 17:49:41 -0600 Matt Mackall m...@selenic.com wrote:
The whole concept is quite hacky and nasty, isn't it?.
It is, which is part of why we were trying to kill it. The primary users
were thing growing buffers ala
On Mon, 2009-02-16 at 09:52 +0800, Herbert Xu wrote:
On Sun, Feb 15, 2009 at 07:28:46PM -0600, Matt Mackall wrote:
Yeah. That sucks. We should probably stick in an skb-friendly slab size
and see what happens on network benchmarks.
I don't see how that's going to help since we don't want
On Friday 13 February 2009 10:37:01 Matt Mackall wrote:
On Fri, 2009-02-13 at 07:09 +0800, Herbert Xu wrote:
On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote:
I would be interested to know how that goes. You always have this
circular issue that if a little more space helps
On Fri, Feb 13, 2009 at 8:20 AM, Nick Piggin nickpig...@yahoo.com.au wrote:
On Friday 13 February 2009 10:37:01 Matt Mackall wrote:
On Fri, 2009-02-13 at 07:09 +0800, Herbert Xu wrote:
On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote:
I would be interested to know how that goes.
On Tue, Feb 10, 2009 at 04:06:53PM +0200, Pekka J Enberg wrote:
Herbert, what do you think of this (untested) patch? Alternatively, we
could do something like kfree_secure() but it seems overkill for this one
call-site.
I don't understand why you want to limit the use of ksize. If
kmalloc
On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote:
Because the API was being widely abused in the nommu code, for example.
I'd rather not add it back for this special case which can be handled
otherwise.
I'm sorry but that's like banning the use of heaters just because
they can
On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote:
I would be interested to know how that goes. You always have this
circular issue that if a little more space helps significantly, then
maybe it is a good idea to explicitly ask for those bytes. Of course
that larger allocation is
On Thu, Feb 12, 2009 at 05:55:04PM +0200, Pekka Enberg wrote:
OK, fair enough, I applied Kirill's patch. Thanks.
Thanks Pekka!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Fri, 2009-02-13 at 07:09 +0800, Herbert Xu wrote:
On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote:
I would be interested to know how that goes. You always have this
circular issue that if a little more space helps significantly, then
maybe it is a good idea to explicitly
On Tue, Feb 10, 2009 at 03:35:03PM +0200, Pekka Enberg wrote:
On Tue, Feb 10, 2009 at 3:21 PM, Kirill A. Shutemov
kir...@shutemov.name wrote:
It needed for crypto.ko
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
That's bit terse for a changelog. I did a quick grep but wasn't
22 matches
Mail list logo
