On Wed, 21 Feb 2007, Pekka Enberg wrote:
> Well, as a reference, the user-space equivalent is defined in SUSv3 as:
>
> "The realloc() function shall change the size of the memory object
> pointed to by ptr to the size specified by size."
The realloc functions intent is to leave the object in
On 2/21/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
Why not? Its a realloc call and these are the classic semantics of
realloc. Otherwise realloc will always move the memory.
Well, as a reference, the user-space equivalent is defined in SUSv3 as:
"The realloc() function shall change the
On Wed, 21 Feb 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > 2. Check if the size specified is larger than the next smallest general
> > cache and only copy if we would really would allocate from a different
> > cache.
>
> Yeah, I was thinking about this too but decided against it
Hi Christoph,
Christoph Lameter wrote:
1. Just do not allow shrinking via realloc. Probably no big loss and best
performance.
Not a big loss if you can afford the wasted memory. But, I don't think
we should do this, there's no way for the caller to know that we will
hold on to the memory
On Wed, 21 Feb 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > Well could you check ksize for the old object first and if ksize <= new size
> > then just skip the copy? I think this may allow you to get rid of the ksize
> > callers.
>
> And not reallocate at all, right? I thought about
Christoph Lameter wrote:
Well could you check ksize for the old object first and if ksize <= new
size then just skip the copy? I think this may allow you
to get rid of the ksize callers.
And not reallocate at all, right? I thought about that but then you
wouldn't be able to use realloc() to
On Wed, 21 Feb 2007, Pekka J Enberg wrote:
> +void *krealloc(const void *p, size_t new_size, gfp_t flags)
> +{
> + void *ret;
> +
> + if (unlikely(!p))
> + return kmalloc_track_caller(new_size, flags);
> +
> + if (unlikely(!new_size)) {
> + kfree(p);
> +
On Wed, 21 Feb 2007, Pekka Enberg wrote:
> On 2/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > please mark this one __must_check.. not storing realloc() return values
> > is one of the more nasty types of bugs... but gcc can help us greatly
> > here ;)
>
> So I guess we want the same
On Wed, 2007-02-21 at 11:33 +0200, Pekka Enberg wrote:
> On 2/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > please mark this one __must_check.. not storing realloc() return values
> > is one of the more nasty types of bugs... but gcc can help us greatly
> > here ;)
>
> So I guess we want
On 2/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)
So I guess we want the same thing for the other allocator functions
(__kmalloc et al) as
On Wed, 2007-02-21 at 10:06 +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> Introduce krealloc() for reallocating memory while preserving contents.
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc
From: Pekka Enberg <[EMAIL PROTECTED]>
Introduce krealloc() for reallocating memory while preserving contents.
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
include/linux/slab.h |1 +
mm/util.c| 34
From: Pekka Enberg [EMAIL PROTECTED]
Introduce krealloc() for reallocating memory while preserving contents.
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
include/linux/slab.h |1 +
mm/util.c| 34 ++
2
On Wed, 2007-02-21 at 10:06 +0200, Pekka J Enberg wrote:
From: Pekka Enberg [EMAIL PROTECTED]
Introduce krealloc() for reallocating memory while preserving contents.
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)
So I guess we want the same thing for the other allocator functions
(__kmalloc et al) as
On Wed, 2007-02-21 at 11:33 +0200, Pekka Enberg wrote:
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)
So I guess we want the same
On Wed, 21 Feb 2007, Pekka Enberg wrote:
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)
So I guess we want the same thing for the
On Wed, 21 Feb 2007, Pekka J Enberg wrote:
+void *krealloc(const void *p, size_t new_size, gfp_t flags)
+{
+ void *ret;
+
+ if (unlikely(!p))
+ return kmalloc_track_caller(new_size, flags);
+
+ if (unlikely(!new_size)) {
+ kfree(p);
+
Christoph Lameter wrote:
Well could you check ksize for the old object first and if ksize = new
size then just skip the copy? I think this may allow you
to get rid of the ksize callers.
And not reallocate at all, right? I thought about that but then you
wouldn't be able to use realloc() to
On Wed, 21 Feb 2007, Pekka Enberg wrote:
Christoph Lameter wrote:
Well could you check ksize for the old object first and if ksize = new size
then just skip the copy? I think this may allow you to get rid of the ksize
callers.
And not reallocate at all, right? I thought about that but
Hi Christoph,
Christoph Lameter wrote:
1. Just do not allow shrinking via realloc. Probably no big loss and best
performance.
Not a big loss if you can afford the wasted memory. But, I don't think
we should do this, there's no way for the caller to know that we will
hold on to the memory
On Wed, 21 Feb 2007, Pekka Enberg wrote:
Christoph Lameter wrote:
2. Check if the size specified is larger than the next smallest general
cache and only copy if we would really would allocate from a different
cache.
Yeah, I was thinking about this too but decided against it (for now) as
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:
Why not? Its a realloc call and these are the classic semantics of
realloc. Otherwise realloc will always move the memory.
Well, as a reference, the user-space equivalent is defined in SUSv3 as:
The realloc() function shall change the
On Wed, 21 Feb 2007, Pekka Enberg wrote:
Well, as a reference, the user-space equivalent is defined in SUSv3 as:
The realloc() function shall change the size of the memory object
pointed to by ptr to the size specified by size.
The realloc functions intent is to leave the object in place if
24 matches
Mail list logo
