[PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc

[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 
unrealistically large queue pair it could happen that kmalloc() is not 
able to allocate the memory. In this case we will return ENOMEM to the 
user so the kernel will not be affected at all. We plan to add vmalloc() 
call in case kmalloc() fails for the next kernel release.
 
Mit freundlichen Grüßen / Kind regards
 
Stefan Roscher
 
eHCA/eHEA Linux Driver Development
IBM Systems &Technology Group, Systems Software Development / FW I/O 
Firmware Entwicklung 2
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2015
E-Mail: stefan.roscher at de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des 
Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, 
HRB 243294



From:
Roland Dreier <rdreier at cisco.com>
To:
Stefan Roscher <ossrosch at linux.vnet.ibm.com>
Cc:
"LinuxPPC-Dev" <linuxppc-dev at ozlabs.org>, LKML 
<linux-kernel at vger.kernel.org>, "OF-EWG" <ewg at lists.openfabrics.org>, 
Roland Dreier <rolandd at cisco.com>, Joachim Fenkes/Germany/IBM at IBMDE, 
Christoph Raisch/Germany/IBM at IBMDE, Alexander Schmidt1/Germany/IBM at IBMDE, 
Stefan Roscher/Germany/IBM at IBMDE, Hoang-Nam Nguyen/Germany/IBM at IBMDE
Date:
21.04.2009 19:34
Subject:
Re: [PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc



 > +             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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090422/b14de834/attachment.htm>