thanks, applied.
> From: Anton Blanchard
> Signed-off-by: Stefan Roscher
please use '@' signs so these are real email addresses.
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
On Tue, 2009-04-21 at 17:16 +0200, Stefan Roscher wrote:
> From: Anton Blanchard
>
> To improve performance of driver ressource allocation,
> replace the vmalloc() call with kmalloc().
Just curious, but how big are these allocations? Why was vmalloc() even
ever used if we know they'll be small?
On Tue, 28 Apr 2009 07:01:32 -0700
Roland Dreier wrote:
> > did you have a chance to take a look at the patchset and will you apply
> it, or
> > are there any outstanding issues we need to address?
>
> I guess it's OK, but definitely 2.6.31 material. I guess I'll stick it
> linux-next soon.
> did you have a chance to take a look at the patchset and will you apply it,
> or
> are there any outstanding issues we need to address?
I guess it's OK, but definitely 2.6.31 material. I guess I'll stick it
linux-next soon.
- R.
___
ewg mailing
Hi Roland,
did you have a chance to take a look at the patchset and will you apply it, or
are there any outstanding issues we need to address?
Regards,
Alex
On Wed, 22 Apr 2009 16:02:28 +0200
Stefan Roscher wrote:
> In case of large queue pairs there is the possibillity of allocation failures
On Wednesday 22 April 2009 04:10:18 pm michael wrote:
> Hi,
>
> I don't take the point, if it is not import use the vmalloc. Why you try
> with a kmalloc
> alloc first? and why do not use kzalloc?
Because kmalloc() is faster than vmalloc() causing a huge performance win
when someone allocates a
In case of large queue pairs there is the possibillity of allocation failures
due to memory fragmentationo with kmalloc().To ensure the memory is allocated
even
if kmalloc() can not find chunks which are big enough, we try to allocate the
memory
with vmalloc().
Signed-off-by: Stefan Roscher
--
Hi Roland,
thanks for the quick review. I was hoping you could apply these changes
for 2.6.30 because this will be the codebase for the next OFED release.
The patch is well tested in HPC environment and we haven't seen any
issues.
Regarding Antons patch you are right. If a user allocates an
unr
> +queue->queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
How big might this buffer be? Any chance of allocation failure due to
memory fragmentation?
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.or
