Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932552AbWARWJO (ORCPT ); Wed, 18 Jan 2006 17:09:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932550AbWARWJO (ORCPT ); Wed, 18 Jan 2006 17:09:14 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:29068 "HELO iolanthe.rowland.org") by vger.kernel.org with SMTP id S932547AbWARWJN (ORCPT ); Wed, 18 Jan 2006 17:09:13 -0500 Date: Wed, 18 Jan 2006 17:09:10 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Benjamin LaHaise cc: Andrew Morton , Chandra Seetharaman , Keith Owens , Kernel development list Subject: Re: [PATCH 1/8] Notifier chain update In-Reply-To: <20060118220122.GH16285@kvack.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 974 Lines: 26 On Wed, 18 Jan 2006, Benjamin LaHaise wrote: > The notifier interface is supposed to be *light weight*. Again, where is that documented? > Adding locks > that get taken on every call basically changes the concept entirely. The > cache misses notifiers add are measurable overhead, with locks being far > worse. Which is worse: overhead due to cache misses or an oops caused by code being called after it was unloaded? Do you have a better proposal for a way to prevent blocking notifier chains from being modified while in use? Or would you prefer to rewrite all the callout routines that currently block, so that all the notifier chains can be made atomic and we don't need the blocking notifier API? Alan Stern - 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/