On Mon, Mar 01, 2010 at 09:24:40PM -0600, Dan Nelson wrote:
> Hm. Even after some reading, I'm not sure how the slabs keep track of which
> elements are allocated or free. I expected to find a bitmap somewhere that
> malloc() sets and free() clears, but I don't see it. Maybe some kernel
> hacke
In the last episode (Mar 01), Shrivatsan said:
> I am looking at the code that allocates and frees kernel memory. I
> understand that allocating kernel memory is quite different from the user
> level mallocs. In case of user level mallocs, we allocate requested size
> + 4 bytes and store the reque
On Thu, Dec 16, 2004 at 04:39:27AM +0300, Kenny Chamber wrote:
> I have a question concerning the use of malloc to allocate small amounts
> of memory for packet wrappers for certain packets.
> Basically, I'm using malloc in much the same way as one would use it in
> a standard userland program: all
On Mon, Nov 03, 2003 at 10:51:58AM +0100, Gerald Heinig wrote:
> Is this true? I seem to remember that FreeBSD has a slab allocator,
> which IIRC is particularly good at allocating small chunks.
You don't specify which version of the kernel you're programming to; so
I'll assume 5.x.
If your alloc
Chris Ptacek wrote:
> I am trying to malloc a large amount of memory for a KLD during load and the
> malloc keeps failing. I am trying to malloc 64-128MB for a memory pool for
> a project I am working on. My system has 196MB of memory and the KLD is
> loaded at startup so I am relativly sure tha
* Chris Ptacek <[EMAIL PROTECTED]> [05 15:22] wrote:
> Hey all, I have a couple questions about kernel mallocs.
>
> I am trying to malloc a large amount of memory for a KLD during load and the
> malloc keeps failing. I am trying to malloc 64-128MB for a memory pool for
> a project I am worki
On Mon, Jul 23, 2001 at 12:37:55PM +0100, vishwanath pargaonkar wrote:
> Hi,
>
> thx for ur reply.
> i wanted to know in side kernel is there any limit to
> the malloc that a user can do.what you told in ur
> previous mail is that at a time user can malloc 4k.but
No. You _can_ malloc ov
Hi,
thx for ur reply.
i wanted to know in side kernel is there any limit to
the malloc that a user can do.what you told in ur
previous mail is that at a time user can malloc 4k.but
suppose i am doing 2k memory allocations. how many
such mallocs i can do?
is there any configuration we can do depen
On Fri, Jul 20, 2001 at 10:17:20AM +0100, vishwanath pargaonkar wrote:
> Hi,
>
> can any one please help me with this. i want allocate
> a memory in the kernel -a buffer of size 2k to 5k.
> can i do it using malloc with second parameter as
> M_TEMP and third as M_WAITOK.
>
> can anybody tell me
* Logan Gabriel <[EMAIL PROTECTED]> [010412 11:50] wrote:
> There is a hard to duplicate race condition in freebsd's
> kernel malloc. Bassically it is possiables for the kernel
> to tsleep way down in vm_page_sleep_busy even when M_NOWAIT
> is spefcied. Under some conditions this can block t
On 11-Aug-99 Matthew Dillon wrote:
> If the interrupt scans or in any way accesses the buffer list,
> you have to disable interrupts temporarily using the appropriate
> spl*() calls whenever your non-interrupt code (i.e. the ioctl code)
> makes modifications to the list. Other
:size - to be malloc'ed. The tail queue holding the newly-
:allocated buffers is a local copy, and not subject to change
:in the event of an interrupt meant for the driver. Given
If the interrupt scans or in any way accesses the buffer list,
you have to disable interrupts temporarily using
On 11-Aug-99 Matthew Dillon wrote:
> If the interrupt scans or in any way accesses the buffer list,
> you have to disable interrupts temporarily using the appropriate
> spl*() calls whenever your non-interrupt code (i.e. the ioctl code)
> makes modifications to the list. Othe
:size - to be malloc'ed. The tail queue holding the newly-
:allocated buffers is a local copy, and not subject to change
:in the event of an interrupt meant for the driver. Given
If the interrupt scans or in any way accesses the buffer list,
you have to disable interrupts temporarily usin
14 matches
Mail list logo