7.0_RC1 slow boot

Arto Huusko

unread,

Jul 12, 2015, 1:47:37 PM7/12/15

to

Hello,

I just tested NetBSD 7.0_RC1, and it seems that 7.0 is *very* slow to
boot compared to 6.1.5. The problem seems to be entirely in the userland
because 7.0 kernel with 6.1.5 userland is just as fast as 6.1.5 kernel.
And based on vmstat -s fork numbers right after boot, the problem is
likely just in the rc system.

Just for the record, I did the tests on a qemu sparc emulator with no
other configuration than rc_configured=YES: 6.1.5 boots in 11 seconds
(with 6.1.5 and 7.0 kernels), 7.0_RC1 takes 45 seconds.

A few vmstat -s numbers after boot:

userland+kernel 6.1.5:
55483 total faults taken
28643 traps
5072 CPU context switches
60741 system calls
285 forks
9765 anon page faults
11357 object faults
13705 total name lookups
11417 good hits
1947 miss

userland+kernel 7.0_RC1:
288771 total faults taken
147872 traps
11634 CPU context switches
159367 system calls
1064 forks
30715 anon page faults
63240 object faults
34700 total name lookups
31061 good hits
2108 miss

I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1, and
vmstat numbers are pretty much the same.
In the not very scientific qemu boot time test -current kernel is also
unfortunately slightly slower to boot 6.1.5 userland than 6.1.5 or 7.0
kernel.

Arto

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Martin Husemann

unread,

Jul 12, 2015, 2:02:19 PM7/12/15

to

On Sun, Jul 12, 2015 at 08:47:13PM +0300, Arto Huusko wrote:
> I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1, and
> vmstat numbers are pretty much the same.

See:
http://mail-index.netbsd.org/tech-userlevel/2015/06/01/msg009153.html

Alan, could you have a look?
Frank, can you file a PR please?

> In the not very scientific qemu boot time test -current kernel is also
> unfortunately slightly slower to boot 6.1.5 userland than 6.1.5 or 7.0
> kernel.

This would be interesting to analyze closer. Sparc is not in the set of
architectures that switches DIAGNOSTIC off on release branches and on
again in -current (AFAICT), so this must be something else.

Martin

Frank Wille

unread,

Jul 12, 2015, 7:18:30 PM7/12/15

to

On Sun, 12 Jul 2015 20:02:03 +0200
Martin Husemann <mar...@duskware.de> wrote:

> On Sun, Jul 12, 2015 at 08:47:13PM +0300, Arto Huusko wrote:
> > I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1,
> > and vmstat numbers are pretty much the same.

I'm happy to hear from more platforms confirming the problem. ;)

It probably isn't noticable on modern multi-core CPUs, but only on older
systems.

> Frank, can you file a PR please?

Done.

> > In the not very scientific qemu boot time test -current kernel is
> > also unfortunately slightly slower to boot 6.1.5 userland than
> > 6.1.5 or 7.0 kernel.

I can also confirm that for Amiga.

--
Frank Wille

Christos Zoulas

unread,

Jul 12, 2015, 10:44:22 PM7/12/15

to

In article <20150713000220...@phoenix.owl.de>,

Frank Wille <fr...@phoenix.owl.de> wrote:
>On Sun, 12 Jul 2015 20:02:03 +0200
>Martin Husemann <mar...@duskware.de> wrote:
>
>> On Sun, Jul 12, 2015 at 08:47:13PM +0300, Arto Huusko wrote:
>> > I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1,
>> > and vmstat numbers are pretty much the same.
>
>I'm happy to hear from more platforms confirming the problem. ;)
>
>It probably isn't noticable on modern multi-core CPUs, but only on older
>systems.
>
>
>> Frank, can you file a PR please?
>
>Done.
>
>
>> > In the not very scientific qemu boot time test -current kernel is
>> > also unfortunately slightly slower to boot 6.1.5 userland than
>> > 6.1.5 or 7.0 kernel.
>
>I can also confirm that for Amiga.

i think we should just import stdbuf and libstdbuf from FreeBSD and:

LD_PRELOAD=/lib/libstdbuf.so
export _STDBUF_O=0
export _STDBUF_E=0

In the rc scripts...

christos

Arto Huusko

unread,

Jul 13, 2015, 6:17:26 AM7/13/15

to

On 12.07.2015 21:02, Martin Husemann wrote:
> On Sun, Jul 12, 2015 at 08:47:13PM +0300, Arto Huusko wrote:
>> I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1, and
>> vmstat numbers are pretty much the same.
>
> See:
> http://mail-index.netbsd.org/tech-userlevel/2015/06/01/msg009153.html

That helped, but only about 1-2 seconds, so with that 7.0_RC1 boot is 43
seconds compared to 11 seconds of 6.1.5. But I looked at other rc
changes in 7.0, and reverting revision 1.94 of etc/rc.subr restored the
boot speed back to the same level as in 6.1.5, and number of forks
dropped back from over 1000 to less than 300.

At a glance the diffs do look like they should not cause any forks, but
maybe someone should take a closer look.

>> In the not very scientific qemu boot time test -current kernel is also
>> unfortunately slightly slower to boot 6.1.5 userland than 6.1.5 or 7.0
>> kernel.
>
> This would be interesting to analyze closer. Sparc is not in the set of
> architectures that switches DIAGNOSTIC off on release branches and on
> again in -current (AFAICT), so this must be something else.

I'll try to see if I can get some more details.

Arto

Eric Haszlakiewicz

unread,

Jul 13, 2015, 8:09:25 AM7/13/15

to

On July 13, 2015 6:14:47 AM EDT, Arto Huusko <arm...@gmail.com> wrote:
>On 12.07.2015 21:02, Martin Husemann wrote:
>> On Sun, Jul 12, 2015 at 08:47:13PM +0300, Arto Huusko wrote:
>>> I also tested 7.99.19, and it is just as slow to boot as 7.0_RC1,
>and
>>> vmstat numbers are pretty much the same.
>>
>> See:
>> http://mail-index.netbsd.org/tech-userlevel/2015/06/01/msg009153.html
>
>That helped, but only about 1-2 seconds, so with that 7.0_RC1 boot is
>43
>seconds compared to 11 seconds of 6.1.5. But I looked at other rc
>changes in 7.0, and reverting revision 1.94 of etc/rc.subr restored the
>boot speed back to the same level as in 6.1.5, and number of forks
>dropped back from over 1000 to less than 300.
>
>At a glance the diffs do look like they should not cause any forks, but
>maybe someone should take a closer look.

That diff appears to replace a simple "-n" test with a function that does an eval, a kill and a expr, the last with an embedded command substitution to run ps, so it'll definitely cause more forks. It's aimed at determining whether some pid is alive, but it seems like an awful lot of work to be doing just for that.

Eric

Martin Husemann

unread,

Jul 13, 2015, 8:30:55 AM7/13/15

to

On Mon, Jul 13, 2015 at 12:09:02PM +0000, Eric Haszlakiewicz wrote:
> That diff appears to replace a simple "-n" test with a function that
> does an eval, a kill and a expr, the last with an embedded command
> substitution to run ps, so it'll definitely cause more forks. It's
> aimed at determining whether some pid is alive, but it seems like an
> awful lot of work to be doing just for that.

Yes, but first thing the function does is basically the same -n test and quick
return - at least that seems to be the intention.

Martin