[gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?

[Duncan]

Mart Raudsepp posted on Thu, 30 Aug 2012 07:27:48 +0300 as excerpted:

> Geode LX700 (433MHz) with 256MB RAM MAKEOPTS=-j2 (single core system)
> gcc (Gentoo 4.5.2 p1.1, pie-0.4.5) 4.5.2
>
> ebuild prepare done before as well.
>
> 1. time ebuild foo configure — real time value
> 2. time ebuild foo compile — real time value
>
> ver           (1)      (2)    (1+2)
> udev-171-r6: 47.2s / 4m36.4 / 5m23.6
> udev-188   : 69.6s / 6m27.2 / 7m36.8


Thanks.  Those are the data-points of an older udev and a current "semi-
integrated" udev that gentoo has "deintegrated" to a point.

Now, for worst-case comparison, on the same machine, what's the 
respective times for a full systemd build?  (I'm not saying actually 
merge it, just configure/compile, plus see the next paragraph.)

Also, note that ebuild foo install only does the install to the fake 
location in PORTAGE_TMPDIR.  It's the ebuild qmerge step that actually 
merges to the live filesystem.  So the install phase should be safe to 
try without actually merging as well, just don't qmerge.  And on some 
packages the install phase actually does enough additional work to be 
worth timing as well.  I don't know if that's the case here or not, but 
it's probably worth testing, just in case.

So far, the results are encouraging.  Higher times, but not THAT much 
higher, with the new version.  But if the worst happens and we really DO 
end up building all of systemd and then throwing most of it away, what's 
the relative times for THAT?  That's actually what I was asking earlier, 
and this gets us part way to the answers, but not all the way.

Regardless, thanks, this is considerably more solid information than was 
available earlier, and not everyone has a geode to actually do the test 
on, so these numbers are a real contribution to the available 
information, indeed! =:^)

(Now I'm wondering just how low I could clock this bulldozer, and whether 
setting uniprocessor kernel command-line-option and downclocking as far 
as possible, plus memory-limiting to say 256MB for my own tests is worth 
the trouble.  FWIW I also have an original atom netbook that's slow 
enough to be interesting, but I do my builds for it in a 32-bit chroot on 
the main machine then rsync them over, and I've not actually updated the 
netbook in over a year, so I'd have to do a seriously major update, then 
figure out how to make the portage tree available on the netbook, to test 
that, and that's DEFINITELY more work than I'm likely to put into such a 
test, near-term anyway, so deliberately crippling the bulldozer is about 
the best I'll get.  But that'd make for an interesting comparison against 
normal performance on this hardware, as well, so I just might do that one 
of these days if I get the urge to do some fiddling.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman