From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755442AbZEKQmU (ORCPT ); Mon, 11 May 2009 12:42:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754025AbZEKQmJ (ORCPT ); Mon, 11 May 2009 12:42:09 -0400 Received: from casper.infradead.org ([85.118.1.10]:34848 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753491AbZEKQmJ (ORCPT ); Mon, 11 May 2009 12:42:09 -0400 Date: Mon, 11 May 2009 09:41:51 -0700 From: Arjan van de Ven To: Kay Sievers Cc: Alan Cox , "Eric W. Biederman" , Peter Zijlstra , Greg KH , Andrew Morton , Fabio Comolli , Greg KH , linux-kernel@vger.kernel.org Subject: Re: [patch 00/13] devtmpfs patches Message-ID: <20090511094151.6014cafb@infradead.org> In-Reply-To: References: <20090509143742.GA27663@kroah.com> <20090510170016.1e3a4d97@infradead.org> <20090511115504.568c9a92@lxorguk.ukuu.org.uk> <20090511141057.24a5f8ed@lxorguk.ukuu.org.uk> <20090511165317.3da5326f@lxorguk.ukuu.org.uk> Organization: Intel X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 11 May 2009 18:28:20 +0200 Kay Sievers wrote: > > It isn't slow. It's just that bootstrapping/re-constructing something > later can obviously never be faster than doing it when the device is > created. the performance gains from doing stuff in batches is obviously well established; CPU caches cause that. Not saying that's a hot factor here, the total only takes 0.01 second after all, but "obviously" isn't true here. > I don't know of any obvious fixes to udev, otherwise I would have > implemented them. there's not much to fix afaics. It'd be nice if it was the 0.06 seconds that Eric gets, but 0.20 isn't all that bad either. > > sh < /sys/initial-device-list > > And you still need to cope with the races, and bring up the event > listener before that. so ? > This is less reliable and always slower than the > kernel provided nodes, besides that your /sys/initial-device-list will > be the same amount of code we need for the node creation right away, > without any of the other benefits, and will require another > special-case tool we don't use today. it's not about the amount of code. It's about in how many useful ways the code can be used! -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org