[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100517103050.21B6.A69D9226@jp.fujitsu.com>
Date: Mon, 17 May 2010 10:34:30 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: kosaki.motohiro@...fujitsu.com, peterz@...radead.org,
xiaosuo@...il.com, akpm@...ux-foundation.org, hnguyen@...ibm.com,
raisch@...ibm.com, rolandd@...co.com, sean.hefty@...el.com,
hal.rosenstock@...il.com, divy@...lsio.com,
James.Bottomley@...e.de, tytso@....edu, adilger@....com,
viro@...iv.linux.org.uk, menage@...gle.com, lizf@...fujitsu.com,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, containers@...ts.linux-foundation.org,
eric.dumazet@...il.com
Subject: Re: [PATCH 1/9] mm: add generic adaptive large memory allocationAPIs
> Peter Zijlstra wrote:
> > NAK, I really utterly dislike that inatomic argument. The alloc side
> > doesn't function in atomic context either. Please keep the thing
> > symmetric in that regards.
>
> Excuse me. kmalloc(GFP_KERNEL) may sleep (and therefore cannot be used in
> atomic context). However, kfree() for memory allocated with kmalloc(GFP_KERNEL)
> never sleep (and therefore can be used in atomic context).
> Why kmalloc() and kfree() are NOT kept symmetric?
In kmalloc case, we need to consider both kmalloc(GFP_KERNEL)/kfree() pair and
kmalloc(GFP_ATOMIC)/kfree() pair. latter is mainly used on atomic context.
To make kfree() atomic help to keep the implementation simple.
But kvmalloc don't have GFP_ATOMIC feautre. that's big difference.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists