Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758888Ab0GPSdX (ORCPT ); Fri, 16 Jul 2010 14:33:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758764Ab0GPSdV (ORCPT ); Fri, 16 Jul 2010 14:33:21 -0400 Message-ID: <4C40A5A0.3010107@redhat.com> Date: Fri, 16 Jul 2010 21:32:00 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Mathieu Desnoyers CC: "H. Peter Anvin" , LKML , Linus Torvalds , Andrew Morton , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Steven Rostedt , Frederic Weisbecker , Thomas Gleixner , Christoph Hellwig , Li Zefan , Lai Jiangshan , Johannes Berg , Masami Hiramatsu , Arnaldo Carvalho de Melo , Tom Zanussi , KOSAKI Motohiro , Andi Kleen , akpm@osdl.org, Jeremy Fitzhardinge , "Frank Ch. Eigler" Subject: Re: [patch 2/2] x86 NMI-safe INT3 and Page Fault References: <20100714154923.947138065@efficios.com> <20100714155804.252253097@efficios.com> <4C405078.20707@redhat.com> <20100716144927.GA22516@Krystal> <4C408D0C.5050709@redhat.com> <20100716165855.GA3836@Krystal> <4C409CBA.1050709@redhat.com> <4C409F62.6030303@zytor.com> <4C40A1BD.4040507@redhat.com> <20100716182240.GA23215@Krystal> In-Reply-To: <20100716182240.GA23215@Krystal> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1187 Lines: 28 On 07/16/2010 09:22 PM, Mathieu Desnoyers wrote: > >> There aren't that many processes at this time (or there shouldn't be, >> don't know how fork-happy udev is at this stage), so the sync should be >> pretty fast. In any case, we can sync only modules that contain NMI >> handlers. >> > USB hotplug is a use-case happening randomly after the system is well there and > running; I'm afraid this does not fit in your module loading expectations. It > triggers tons of events, many of these actually load modules. > How long would vmalloc_sync_all take with a few thousand mm_struct take? We share the pmds, yes? So it's a few thousand memory accesses. The direct impact is probably negligible, compared to actually loading the module from disk. All we need is to make sure the locking doesn't slow down unrelated stuff. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/