Re: Building Kernel and World with -j

2017-01-23 Thread Kevin Oberman 
On Mon, Jan 23, 2017 at 6:10 AM, Lowell Gilbert <
freebsd-stable-lo...@be-well.ilk.org> wrote:

> Walter Parker  writes:
>
> > For decades there has always been a warning not to do parallel builds of
> > the kernel or the world (Linux kernel builds also suggest not to do
> this).
> >
> > Every once in a while, I see people post about 5 minutes. This only way I
> > can see this happening is by doing a parallel build (-j 16 on a Xeon
> > Monster box).
> >
> > Are parallel builds safe? If not, what are actual risk factors and can
> they
> > be mitigated?
>
> As a general rule, it's safe. But don't report failures from a
> parallel build.
>
> This is not so much an issue of parallel builds being unsupported
> as of the logs being harder to read.


Use of parallel builds of world and kernel are and have been supported
since at least 10.0. If a parallel build fails, the first step is usually
to do a single-job build. If it succeeds, there is a bug in the make
scripts that should be reported. If the single-job build also fails, a bug
should be reported with any errors included from the non-parallel build as
the parallel build makes the error context very difficult or even
impossible to determine from the log.

Generally, I think the number of jobs should be slightly greater than the
number of available CPU threads. Back in 10.0 days I ran some tests that
showed the for 4 and 8 thread systems the improvements for large numbers of
jobs peaked at about CPU thread count + 2 and significantly larger numbers
of jobs caused a slight deterioration in performance. This was not true on
early hyper-threaded CPUs which did not effectively optimize
hyper-threading and things may have changed in the 6 or 7 years since I
tested and may be very different for systems with large numbers of threads
seen in servers today.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Horrible zpool resilver perormance on local hast

2017-01-23 Thread Pete French 
Partially answering my own question here, as it occured to
me that the zpool is scattering writes across the disc in 4k blocks,
but hast has a minimum extent size of 2meg by default. Thats eems like
a likely culprit for the 'dirty blocks' multiplcation I am seeing.

I shrunk down the extent size to 16k to see if that helped, and I
now see a far smaller dirty block to written block ration, but
also the write speed has now shrunk down even more to around 50k/s :-(

Any advice on tuning this properly ?

-pete.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Horrible zpool resilver perormance on local hast

2017-01-23 Thread Pete French 
I have a pair of machines running hast cross two pairs of
drives - i.e. 4 drives total, two in each box, and hence
two hast resources, cbert0 and cebrt1.

Its been running mysql fir a long time, but there only 6 gig
of data actually in use in the pool. I rebuilt the secondary
machine, and wanted to resync the hast devices, but that would involve
copying 450 gig for only 6 gig of actual data.

"easy" I though, "just rebuild each has device in the pool
so it only has the current data dirty"

seems reasonbale enough ?

so I disconnected one bit of the mirror, did a 'hast create' to
zero it, and reattached it to the mirror.

(note that the secondary side is entirely disconnected, this is local
to one machine).

what I am seeing is that the zpool is resilvering at a rate
of 170K/s - currently it says this:

622M scanned out of 6.53G at 170K/s, 10h9m to go

But the hastctl status outout says this:

  status: degraded
  workerpid: 950
  dirty: 136363114496 (127GB)
  statistics:

I onyl expect dirty blocks when the ZFS has ritten something -0 127 gig
dirty seems excessive for 622 meg written!

anyone got any idea what might be happening ?

-pete.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building Kernel and World with -j

2017-01-23 Thread Lowell Gilbert 
Walter Parker  writes:

> For decades there has always been a warning not to do parallel builds of
> the kernel or the world (Linux kernel builds also suggest not to do this).
>
> Every once in a while, I see people post about 5 minutes. This only way I
> can see this happening is by doing a parallel build (-j 16 on a Xeon
> Monster box).
>
> Are parallel builds safe? If not, what are actual risk factors and can they
> be mitigated?

As a general rule, it's safe. But don't report failures from a
parallel build.

This is not so much an issue of parallel builds being unsupported
as of the logs being harder to read.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building Kernel and World with -j

2017-01-23 Thread tech-lists 
On 23/01/2017 06:57, Walter Parker wrote:
> Hi,
> 
> For decades there has always been a warning not to do parallel builds of
> the kernel or the world (Linux kernel builds also suggest not to do this).
> 
> Every once in a while, I see people post about 5 minutes. This only way I
> can see this happening is by doing a parallel build (-j 16 on a Xeon
> Monster box).
> 
> Are parallel builds safe? If not, what are actual risk factors and can they
> be mitigated?

I remember warnings to the effect that while buildworld and buildkernel
was safe, installworld and installkernel were not.

I use -j32 on i7 monster boxes.

-- 
J.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building Kernel and World with -j

2017-01-23 Thread Steven Hartland 

On 23/01/2017 07:24, Sergei Akhmatdinov wrote:

On Sun, 22 Jan 2017 22:57:46 -0800
Walter Parker  wrote:

For decades there has always been a warning not to do parallel builds of
the kernel or the world (Linux kernel builds also suggest not to do this).

Every once in a while, I see people post about 5 minutes. This only way I
can see this happening is by doing a parallel build (-j 16 on a Xeon
Monster box).

Are parallel builds safe? If not, what are actual risk factors and can they
be mitigated?

Not only do I use -j, I also use ccache.

Another option is to use WITH_META_MODE=YES, that's where most of the 5-minute
reports come from, I imagine. I haven't used it myself.

My kernel takes 10 minutes with world taking about two hours. I generally just
leave them building overnight.

The risks of parallel builds are mostly in the past, concurrency was still just
coming out and there were chances that something would get compiled before it's
dependency, breaking your compile and wasting all of those hours.

Cheers,

We always use -j for both kernel and world for years.

While there's been a few niggles if the clock is out and its a rebuild 
they have been few and far between.


Current cut down kernel build time is 1m and world build time is 22m 
here for FreeBSD 11.0-RELEASE on a dual E5-2640.


Regards
Steve
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"