Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753069AbbBXKxf (ORCPT ); Tue, 24 Feb 2015 05:53:35 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:37922 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbbBXKxd (ORCPT ); Tue, 24 Feb 2015 05:53:33 -0500 Date: Tue, 24 Feb 2015 11:53:28 +0100 From: Ingo Molnar To: Jiri Kosina Cc: Vojtech Pavlik , Josh Poimboeuf , Peter Zijlstra , Andrew Morton , Ingo Molnar , Seth Jennings , linux-kernel@vger.kernel.org, Linus Torvalds , Arjan van de Ven , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , live-patching@vger.kernel.org Subject: Re: live kernel upgrades (was: live kernel patching design) Message-ID: <20150224105328.GB20698@gmail.com> References: <20150221181852.GA8406@gmail.com> <20150221191607.GA9534@gmail.com> <20150221194840.GA10126@gmail.com> <20150222084601.GA23491@gmail.com> <20150222094639.GA23684@gmail.com> <20150222104841.GA25335@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1527 Lines: 38 * Jiri Kosina wrote: > [...] We could optimize the kernel the craziest way we > can, but hardware takes its time to reinitialize. And in > most cases, you'd really need to reinitalize it; [...] If we want to reinitialize a device, most of the longer initialization latencies during bootup these days involve things like: 'poke hardware, see if there's any response'. Those are mostly going away quickly with modern, well-enumerated hardware interfaces. Just try a modprobe of a random hardware driver - most initialization sequences are very fast. (That's how people are able to do cold bootups in less than 1 second.) In theory this could also be optimized: we could avoid the reinitialization step through an upgrade via relatively simple means, for example if drivers define their own version and the new kernel's driver checks whether the previous state is from a compatible driver. Then the new driver could do a shorter initialization sequence. But I'd only do it only in special cases, where for some reason the initialization sequence takes longer time and it makes sense to share hardware discovery information between two versions of the driver. I'm not convinced such a mechanism is necessary in the general case. Thanks, Ingo -- 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/