thanks dave,
rebooting helped -- apparently, the memory must have
been fragmented badly. i'll keep an eye on this. meanwhile, i'll look into the
possibility of reducing the size of memory to be allocated.
gurol
-----Original Message-----I have seen cases where memory gets fragmented enough that you can't allocate chunks of memory that seem ridiculously small compared to the amount of nominal available memory. The problem is that the memory is not physically contiguous and needs to be shuffled in order to satisfy the request.
From: Dave Grothe [mailto:[EMAIL PROTECTED]
Sent: Monday, May 03, 2004 6:42 PM
To: Gurol Akman; '[EMAIL PROTECTED]'
Subject: Re: [Linux-streams] kmem_alloc failure
The KM_NOSLEEP is contributing to this, but the path forward from there has pitfalls. Under the KM_NOSLEEP option the kernel is not allowed to shuffle the page table because that would require a sleep.
One possibility is to try what you are doing fresh after a reboot. It's a kludge, but might work.
Your call is similar to the lis_alloc_atomic() function. You could try using lis_alloc_kernel() as a substitute. However, depending upon the context of the call you could run into trouble in LiS-2.16.x. The problem is that the kernel may need to sleep to fiddle with the page table to satisfy your request, and in LiS-2.16.x you will be implicitly holding a spin lock when you make that call. This could lead to trouble.
If you use LiS-2.17.x (numbered, not lettered, version) that same context will be holding a semaphore instead of a spin lock and you will be safe to use lis_alloc_kernel(). You will need to recompile your driver in the context of LiS-2.17 headers if you want to try this.
Maybe someone else has a more elegant idea.
-- Dave
At 07:09 PM 5/3/2004, Gurol Akman wrote:
kmem_zalloc(size, KM_NOSLEEP) call from within my driver fails under LiS-2.16.18 and the following info gets printed:
__alloc_pages: 8-order allocation failed (gfp=0x20/0)
lis_get_free_pages: called from .... #...: nbytes=631396 order=8 total=1048576 allocation failed
when i check on /proc/meminfo, i see the following:
MemFree: 20752 kB
which suggests that there is sufficient memory on the system.
what may be causing the kmem_zalloc failure? could KM_NOSLEEP be the cause?
thanks & regards -- GA
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004
