Re: kmalloc_in_driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 01, 2004 at 20:25:49 +0530, mohanlal jangir wrote:
> Here are some points:
> 1. If you don't need allocated memory, free it (kfree)
> 2. There is a limit on memory allocated (I remember some low water mark). If
> you specify GFP_KERNEL then memory will be allocated only if available
> memory is more than low water mark. If you specify GFP_ATOMIC kernel will
> try to allocate memory even if available memory is less than low water mark.

The talk about water marks sounds strange to me. From what I know about
kmalloc, it allocates *continuous* memory from the page allocator via
a generic slab cache (which splits aquired pages to equaly-sized
chunks). There is no limit for number of chunks from a slab cache, as
far as I know. 

The flags passed to kmalloc are passed right through to the page
allocator where they mean:
GFP_KERNEL -- No restrictions, try ultimately hard. If pages can't be
    found right away, all sorts of operations that may free some up are
    triggered, including OOM kill. May sleep.
GFP_NOFS -- Do not trigger filesystem access. May wait for buffers and
    shrink caches, but will not call filesystem methods. May sleep, not
    sure about OOM kill.
GFP_NOIO -- Do not do any kind of IO. Only shrink caches. May sleep, not
    sure about OOM kill.
GFP_ATOMIC -- Do NOT SLEEP. This might be specified in interrupt and
    softirq context. It is relatively likely to fail.

> 3. Why you get segment fault.. check for memory allocation success or
> failure.

Yes, this must be done in any case, especialy when allocating more than
PAGE_SIZE chunks. Fragmentation might cause kmalloc to fail even though
there enough memory free.

> 4. Why you want to delay timer interrupt. If you want to delay your task,
> there are many options available. As far as I know, timer interrupt handler
> can only be interrupted if some higher priority interrupt occurs (say
> hardware failure).

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux