From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Jenkins Date: Thu, 23 Oct 2008 16:10:13 +0000 Subject: Re: replace in-memory rules array with match/action token list Message-Id: <4900A1E5.9020604@tuffmail.co.uk> MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------020904050905030806080403" List-Id: References: <4900419F.7010405@tuffmail.co.uk> In-Reply-To: <4900419F.7010405@tuffmail.co.uk> To: linux-hotplug@vger.kernel.org This is a multi-part message in MIME format. --------------020904050905030806080403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Kay Sievers wrote: > On Thu, Oct 23, 2008 at 16:16, Alan Jenkins wrote: > >> Kay Sievers wrote: >> >>> On Thu, Oct 23, 2008 at 13:34, Alan Jenkins wrote: >>> >>>> Alan Jenkins wrote: >>>> >>>> >>>>>> The in-memory rule array of a common desktop distro install took: >>>>>> 1151088 bytes >>>>>> with the token list: >>>>>> 109232 bytes tokens (6827 * 16 bytes), 71302 bytes buffer >>>>>> >>>>>> >>>>> Sounds great from a performance point of view. >>>>> > > >> It's still takes over five times >> as long, but I can't see anything unexpected happening. >> > > Are you sure, you don't log/print debug messages somewhere? We got a > few more dbg() messages in the code. > > Kay > No. I've done that before, and the messages ended up in /var/log/daemon.log. I checked it in case there were errors, and I didn't see any debug messages there. Oprofile said that most of the time was in udevd, and it wasn't in a debug function. Actually, the biggest increase was in "system" time. read_hpet was the top entry at 6%, hrtimers featured heavily in general, and I traced it back to sys_nanosleep(). Which I thought might implicate wait_for_file... Hmm. There's also a call usleep() in rename_netif(). Perhaps this error message is significant: "error changing netif name ath0 to ath1: Device or resource busy" It only happens with the bad version. The good version doesn't try to rename the interface from "ath0". I've attached my rules file. But this error should cause rename_netif() to return without calling usleep(). The only other high-res sleep in udevd is the usleep() in wait_for_file(). And anticipating your next question: # grep WAIT /etc/udev/rules.d/* /etc/udev/rules.d/05-udev-early.rules:ACTION=="add", KERNEL=="[0-9]*:[0-9]*", SUBSYSTEM=="scsi", WAIT_FOR_SYSFS="ioerr_cnt" So I have two identifiables 1) The attached rules are being interpreted differently, changing the name of the device. 2) wait_for_file is causing a lot more overhead for some reason. Thanks Alan --------------020904050905030806080403 Content-Type: text/plain; name="70-persistent-net.rules" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="70-persistent-net.rules" IyBUaGlzIGZpbGUgbWFpbnRhaW5zIHBlcnNpc3RlbnQgbmFtZXMgZm9yIG5ldHdvcmsgaW50 ZXJmYWNlcy4KIyBTZWUgdWRldig3KSBmb3Igc3ludGF4LgojCiMgRW50cmllcyBhcmUgYXV0 b21hdGljYWxseSBhZGRlZCBieSB0aGUgNzUtcGVyc2lzdGVudC1uZXQtZ2VuZXJhdG9yLnJ1 bGVzCiMgZmlsZTsgaG93ZXZlciB5b3UgYXJlIGFsc28gZnJlZSB0byBhZGQgeW91ciBvd24g ZW50cmllcy4KCiMgUENJIGRldmljZSAweDE2OGM6MHgwMDFjIChhdGhfcGNpKQpTVUJTWVNU RU09PSJuZXQiLCBEUklWRVJTPT0iPyoiLCBBVFRSU3thZGRyZXNzfT09IjAwOjE1OmFmOjg3 OjQzOjlmIiwgQVRUUlN7dHlwZX09PSIxIiwgTkFNRT0iYXRoMCIKCiMgVVNCIGRldmljZSAw eDA2OWE6MHgwMzE4IChjZGNfZXRoZXIpClNVQlNZU1RFTT09Im5ldCIsIERSSVZFUlM9PSI/ KiIsIEFUVFJTe2FkZHJlc3N9PT0iMDA6MWI6OWU6MTk6NDU6OGYiLCBBVFRSe3R5cGV9PT0i MSIsIE5BTUU9ImV0aDAiCgojIFBDSSBkZXZpY2UgMHgxOTY5OjB4MjA0OCAoYXRsMikKU1VC U1lTVEVNPT0ibmV0IiwgRFJJVkVSUz09Ij8qIiwgQVRUUlN7YWRkcmVzc309PSIwMDoxZjpj NjoyODpiNDpmNyIsIEFUVFJ7dHlwZX09PSIxIiwgTkFNRT0iZXRoMSIKCiMgVVNCIGRldmlj ZSAweDoweCAoY2RjX2V0aGVyKQpTVUJTWVNURU09PSJuZXQiLCBBQ1RJT049PSJhZGQiLCBE UklWRVJTPT0iPyoiLCBBVFRSe2FkZHJlc3N9PT0iMDA6MWI6OWU6MTk6NDU6OGYiLCBBVFRS e3R5cGV9PT0iMSIsIEtFUk5FTD09ImV0aCoiLCBOQU1FPSJldGgyIgoKIyBQQ0kgZGV2aWNl IDB4MTY4YzowMDAwOjAxOjAwLjAgKGF0aDVrX3BjaSkKU1VCU1lTVEVNPT0ibmV0IiwgQUNU SU9OPT0iYWRkIiwgRFJJVkVSUz09Ij8qIiwgQVRUUnthZGRyZXNzfT09IjAwOjE1OmFmOjg3 OjQzOjlmIiwgQVRUUnt0eXBlfT09IjEiLCBLRVJORUw9PSJhdGgqIiwgTkFNRT0iYXRoMSIK --------------020904050905030806080403--