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 file uma_int.h, but I don't quite
> understand the relation between slabs, zones and keg. How do we determine
> the size of the memory that we are trying to free from given the virtual
> address?
I'm not too familiar with the kernel malloc, but it looks like each keg
holds
Hi,
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 requested size in the
additional 4 bytes.
However,
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
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: allocating small chunks and freeing them
again a short(ish) time later.
A
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
Hi all,
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: allocating small chunks and freeing them
again a short(ish) time
Hi all,
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: allocating small chunks and freeing them
again a short(ish) time
* Hiten Pandya <[EMAIL PROTECTED]> [020601 09:35] wrote:
>
> As of now, I have changed this to just use M_WAITOK and malloc() call, but
> I was wondering if anyone can guide me on this GFP_NOFS alternative. Also,
> Alfred to told me on IRC to just #define M_NOFS 0 for now, and then worry
> about
Hi All.
I was wondering if there is an alternative to the GFP_NOFS flag provided
in Linux Kernel Malloc [kmalloc() & kfree()] for FreeBSD, or is there any
info. I am missing?
Linux calls the kmalloc() system call as:
[ an extract from jfs_dtree.c (jfs4bsd) ]
%%%
ciKey.name =
(wch
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
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 what M_TEMP means .what is maximum
malloc i can do with M_TEMP?
will the OS allow me to
* 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 co
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 the kernel
completly.
Attatched is a kernel module
I was wondering if we could pass an additional flag to malloc
M_NOPHYS that would mean the kernel is free to move the physical
location of the memory.
It would signify things that the memory:
1) won't be used for backing DMA.
2) won't be entered into another kernel memory map.
This will allo
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
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an io
: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
We are experiencing what appears to be a memory corruption
problem with a kernel device driver running under FreeBSD
2.2.8-STABLE with the CAM patches.
The driver manages a series of memory buffers implemented
using a singly-linked tail list. The number and size of
buffers may be changed via an i
25 matches
Mail list logo
