From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752662AbYKRLl6 (ORCPT ); Tue, 18 Nov 2008 06:41:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752006AbYKRLlt (ORCPT ); Tue, 18 Nov 2008 06:41:49 -0500 Received: from cn.fujitsu.com ([222.73.24.84]:63378 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752007AbYKRLls (ORCPT ); Tue, 18 Nov 2008 06:41:48 -0500 Message-ID: <4922A93B.6060102@cn.fujitsu.com> Date: Tue, 18 Nov 2008 19:38:35 +0800 From: Lai Jiangshan User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nick Piggin CC: Andrew Morton , Johannes Weiner , David Miller , Dave Airlie , Paul Menage , kamezawa.hiroyu@jp.fujitsu.com, Balbir Singh , Arjan van de Ven , Jan Kara , Jes Sorensen , KOSAKI Motohiro , dada1@cosmosbay.com, Alexey Dobriyan , Jens Axboe , Linux Kernel Mailing List , "Paul E. McKenney" , Nick Piggin , Al Viro , Rik van Riel , Pekka Enberg Subject: Re: [PATCH V2 1/4] vmalloc: introduce vfree_atomic() References: <492162E4.9080902@cn.fujitsu.com> <20081117131440.GB29931@cmpxchg.org> <492281F7.3000107@cn.fujitsu.com> <200811182019.44064.nickpiggin@yahoo.com.au> In-Reply-To: <200811182019.44064.nickpiggin@yahoo.com.au> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nick Piggin wrote: > On Tuesday 18 November 2008 19:51, Lai Jiangshan wrote: >> fdtable and sysipc use vfree() in RCU callback. this patch >> introduce vfree_atomic() for them. > > AFAIKS, vfree is usable from atomic context? What am I missing? Hi, Nick Piggin, Sorry for misled you. fdtable and sysipc use vfree() in RCU callback.(_but defer it by schedule_work()_) current vfree() is not usable from atomic context, so this patches are worthy. even if vfree() is usable from atomic context soon, [PATCH 3/4] [PATCH 4/4] are still worthy now. Because these two patches are independent from vfree().(just needs to be changed one or two lines when vfree() is usable from atomic context) I suggest we can use vfree_atomic() before vfree() is available for atomic context. Because fdtable and sysipc need a grace way for using RCU and vmalloc/vfree. (actually, fdtable and sysipc have implemented they own "vfree_atomic()", but it's very ugly) Thanx, Lai. > Actually, one could argue that we don't want to perform such > costly operations in the atomic context, however with lazy > unmapping, vfree is very cheap now (amortized, at least). > I'm looking forward to vfree() is available for atomic context. > But it should be much cheaper on average not to schedule this in > another context. > > If there was any concern about the TLB flush from atomic context, > we should just defer the lazy flushing, rather than every single > vunmap. > > >