Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I once wrote a kernel module processing packets on a 10Gbs link. I used <code>vmalloc</code> to allocate about 1GByte of continuous (virtual) memory to put a static size hash table into it to perform connection tracking (<a href="https://github.com/diekmann/cctrack/blob/master/code/PF_RING-4.7.1/kernel/plugins/cctrack_hash.c" rel="nofollow noreferrer">code</a>).</p> <p>If you know how much memory you need, I recommend to pre-allocate it. This has two advantages</p> <ul> <li>It is fast (no mallocing/freeing at runtime)</li> <li>You don't have to think of a strategy if <code>kmalloc(_, GFP_ATOMIC)</code> can not return you memory. This can actually happen quite often under heavy load.</li> </ul> <p>Disadvantage</p> <ul> <li>You might allocate more memory then necessary.</li> </ul> <p>So, for writing a special-purpose kernel module, please pre-allocate as much memory as you can get ;)</p> <p>If you write a kernel module for commodity hardware used by many novice users, it would be nice to allocate memory on demand (and waste less memory).</p> <hr> <p>Where do you allocate memory? <code>GFP_ATOMIC</code> can only return a very small amount of memory and should only be used if your memory allocation cannot sleep. You can use <code>GFP_KERNEL</code> when it is safe to sleep, e.g., not in interrupt context. See <a href="https://stackoverflow.com/questions/116343/what-is-the-difference-between-vmalloc-and-kmalloc">this question</a> for more. It is safe to use <code>vmalloc</code> during module initialization to pre-allocate all you memory.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload