From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 48154A47 for ; Wed, 27 Aug 2014 23:05:31 +0000 (UTC) Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C50DD20298 for ; Wed, 27 Aug 2014 23:05:30 +0000 (UTC) Date: Wed, 27 Aug 2014 19:05:27 -0400 From: Theodore Ts'o To: Masami Hiramatsu Message-ID: <20140827230527.GX11317@thunk.org> References: <20140819144839.GA1270@thunk.org> <20140819145547.GB18536@roeck-us.net> <53FB17A7.9090209@hitachi.com> <53FC1A11.1000700@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FC1A11.1000700@hitachi.com> Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] No more module removal -- Unconference track List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Aug 26, 2014 at 02:24:33PM +0900, Masami Hiramatsu wrote: > There could be. However, in usual usecases, I guess people will not want > to unload it. Systemtap or something "additional" module users will > need to unload modules. (kpatch could be one of them, but I also think > no one want to remove applied patches anyway.) > > I just tried to show that the kmodule unload is the one who uses > stop_machine heavily but it is not necessary :) Right, but if the argument that kmodule unload is slow on huge NUMA machines is that Rusty submits a patch which gets rid of the support for module unload entirely, then that would be very sad. (And **really** screw over systemtap...) - Ted