From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: linux-hotplug@vger.kernel.org
Subject: Re: [GIT] Experimental threaded udev
Date: Thu, 28 May 2009 15:39:04 +0000 [thread overview]
Message-ID: <4A1EB018.4030406@tuffmail.co.uk> (raw)
In-Reply-To: <4A1EA138.10400@tuffmail.co.uk>
Kay Sievers wrote:
> On Thu, May 28, 2009 at 16:35, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
>
>> Now available for your delight and/or horror.
>>
>> <http://github.com/sourcejedi/udev/commits/threading-v0.3>
>>
>> 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?
>
Single CPU - its my Celeron 630Mhz netbook.
> 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?
>
> Thanks,
> Kay
>
I'll have a look on my Core2Duo desktop. My netbook core is much slower
than a C2D desktop, but it does require explanation.
There are a couple of global locks. The selinux context is per-process,
so that's locked. If you don't have full close-on-exec support, it has
to fallback to locking. I haven't tested the full close-on-exec support
yet.
My memory says my desktop machine steams through coldplug in a fraction
of a second, but I've not measured it recently.
Thanks
Alan
next prev parent reply other threads:[~2009-05-28 15:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-28 14:35 [GIT] Experimental threaded udev Alan Jenkins
2009-05-28 15:09 ` Kay Sievers
2009-05-28 15:39 ` Alan Jenkins [this message]
2009-05-29 17:53 ` Alan Jenkins
2009-05-29 18:11 ` Kay Sievers
2009-06-01 2:41 ` Kay Sievers
2009-06-01 9:29 ` Alan Jenkins
2009-06-01 11:32 ` Kay Sievers
2009-06-01 12:33 ` Kay Sievers
2009-06-01 13:30 ` Kay Sievers
2009-06-01 13:46 ` Alan Jenkins
2009-06-01 13:57 ` Kay Sievers
2009-06-01 16:22 ` Kay Sievers
2009-06-01 16:24 ` Alan Jenkins
2009-06-01 19:39 ` Kay Sievers
2009-06-02 4:58 ` Kay Sievers
2009-06-02 9:13 ` Alan Jenkins
2009-06-02 9:26 ` Alan Jenkins
2009-06-02 11:39 ` Kay Sievers
2009-06-02 14:05 ` Kay Sievers
2009-06-03 19:44 ` Kay Sievers
2009-06-03 20:46 ` Alan Jenkins
2009-06-03 22:20 ` Kay Sievers
2009-06-03 23:53 ` Kay Sievers
2009-06-06 14:20 ` Kay Sievers
2009-06-06 17:01 ` Bryan Kadzban
2009-06-08 11:45 ` Scott James Remnant
2009-06-08 16:29 ` Bryan Kadzban
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A1EB018.4030406@tuffmail.co.uk \
--to=alan-jenkins@tuffmail.co.uk \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).