From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Jenkins Date: Fri, 29 May 2009 17:53:33 +0000 Subject: Re: [GIT] Experimental threaded udev Message-Id: <4A20211D.4050206@tuffmail.co.uk> List-Id: References: <4A1EA138.10400@tuffmail.co.uk> In-Reply-To: <4A1EA138.10400@tuffmail.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Kay Sievers wrote: > On Thu, May 28, 2009 at 16:35, Alan Jenkins wrote: > >> Now available for your delight and/or horror. >> >> >> >> For now, I'm still treating this as a patch series. That is, I may >> publish future versions with a rewritten history. I'll preserve the old >> branches though. >> >> It turns out the MADV_DONTFORK hack I was so proud of is >> implementation-dependant, i.e. a dirty hack. However, I'm confident >> that glibc can and should be modified to do it for all programs. And it >> is so worth it. On my test machine, threading alone goes from 2s >> boot-time coldplug to 1.3-ish. MADV_DONTFORK takes it down to 0.7-ish. >> The hack is contained in the last patch, "when forking a program, only >> copy the stack of the _current_ thread". >> > > Is that a single or dual CPU box? > > With the threaded version, it's 0.18 (1.51 -> 1.33) seconds faster > here for a full coldplug run on a: > Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz. > > It might be that the threaded version will only behave that much > better on a single CPU machine? > No, it's not that. I'm afraid the result of ~0.7 seconds result was an accident; the bootchart looks suspicious and it didn't obtain when I retested. The "fixed" version of the last patch doesn't work, and I don't think it can. The version that crashed on boot may be useful for comparison purposes though. I will try and see how much I can reduce the page fault overhead without using threads. Maybe just recycling the event processes would bring similar gains, with less of the risks of threads. Alan