Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

[Steve Kargl]

On Fri, May 26, 2017 at 09:57:16PM +, Rick Macklem wrote:
> I have now found I can get rid of almost all of the degradation by building 
> the
> recent kernel with
> options SCHED_4BSD
> instead of
> options SCHED_ULE
> 
> The 1yr old kernel was built with SCHED_ULE, so the degradation is some change
> to the kernel since Apr. 12, 2016 that affects SCHED_ULE but not SCHED_4BSD.
> 
> Any ideas?
> 

What is the load on the system?  A long time ago [1], I pointed out
that ULE performs very poorly if there is an over commit situation.
To boil it down to something simple, the MPI master process on a SMP
system with N processers would fork N+1 processes where each process
is essentially independent and cpu-bound.  N-1 of the processes would
be pinned to N-1 cpus and run with nearly 100% cpu usage.  The N and
N+1 processes would be pinned to a single CPU.  The master process would
then need to wait for the N and N+1 processes to complete before moving on.
Note MPI isn't necessary to show the problem.  Simply have an over
commit situation with cpu intensive processes coudl kill ULE preformance.
4BSD has never exhibited this problem.

[1] http://freebsd.1045724.x6.nabble.com/ULE-scheduling-oddity-td3911224.html

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

[Rick Macklem]

To briefly summarize the previous post related to perf. degradation when 
running a
recent kernel...
- kernel build running 1yr old kernel took 100minutes
- same kernel build running recent kernel 148minutes
(ie. Almost a 50% degradation.)
As noted in the last post, I got rid of most of the degradation by disabling 
SMP.

- same kernel build running recent kernel with SCHED_4BSD   104minutes

I have now found I can get rid of almost all of the degradation by building the
recent kernel with
options SCHED_4BSD
instead of
options SCHED_ULE

The 1yr old kernel was built with SCHED_ULE, so the degradation is some change
to the kernel since Apr. 12, 2016 that affects SCHED_ULE but not SCHED_4BSD.

Any ideas?

Since GENERIC uses SCHED_ULE, it would be nice to see good perf. with that 
option.
However, recommending "options SCHED_4BSD" is nicer than recommending disabling
SMP;-)

rick
ps: I tried the 1yr old net driver in the recent kernel and it had no effect on 
perf.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

src.conf clang x-build flags

[Beeblebrox]

Is there any hope we will get src.conf flags to specify which clang x-build
tools world builds? For example build for i386 but not ARM.?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

[Bryan Drewery]

On 5/26/2017 8:20 AM, Bryan Drewery wrote:
> For those running FreeBSD head, the ABI was majorly changed in r318736
> for 64-bit inodes.  This change was *backwards compatible* but not
> *forward compatible*.  This is normal and expected.
> 
> For Pkg users:
> 
> You are advised to upgrade your system past r318736 soon or avoid using
> official packages until you do.  Portmgr may upgrade the package
> builders at any time and without much notice.

I had forgotten a detail here.  The package builds are all automated.
The source jails are automatically updated before a build.  The package
builder's kernel doesn't matter here.  So head package builds _will_ be
ABI broken for systems older than r318736 either now or in the next day
or two once the builds finish and upload to the mirrors.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

[Ed Maste]

On 26 May 2017 at 12:18, Kurt Jaeger  wrote:
> Hi!
>
>> For those running FreeBSD head, the ABI was majorly changed in r318736
>> for 64-bit inodes.  This change was *backwards compatible* but not
>> *forward compatible*.  This is normal and expected.
>
> Is any fall-out from this change already handled or is it wise
> to wait a few more days ?

All fallout I'm aware of is due to either taking a shortcut and
skipping the reboot after installing the new kernel, or running a
custom kernel without COMPAT_FREEBSD11 in the config (required to
support running the old world on the new kernel). Both of these are
(now) explicitly called out in UPDATING. So as long as those steps are
followed it should be fine.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

[Kurt Jaeger]

Hi!

> For those running FreeBSD head, the ABI was majorly changed in r318736
> for 64-bit inodes.  This change was *backwards compatible* but not
> *forward compatible*.  This is normal and expected.

Is any fall-out from this change already handled or is it wise
to wait a few more days ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

(head users) 64-bit inodes: Packages heads up and Poudriere errors

[Bryan Drewery]

For those running FreeBSD head, the ABI was majorly changed in r318736
for 64-bit inodes.  This change was *backwards compatible* but not
*forward compatible*.  This is normal and expected.

For Pkg users:

You are advised to upgrade your system past r318736 soon or avoid using
official packages until you do.  Portmgr may upgrade the package
builders at any time and without much notice.

For Poudriere users:

What this means is that you may see warnings like this in Poudriere:

> [00:00:01] >> Warning: !!! Jail is newer than host. (Jail: 1200031, Host: 
> 1200030) !!!
> [00:00:01] >> Warning: This is not supported.
> [00:00:01] >> Warning: Host kernel must be same or newer than jail.
> [00:00:01] >> Warning: Expect build failures.

This warning is quite old and usually can be ignored as the
__FreeBSD_version number it is tracking is normally bumped for minor
things.  Large ABI breakage is relatively rare.  In this case it matters
though.

...
> [00:00:03] >> Starting jail exp-head-commit-test
> [00:00:03] >> Error: Unable to execute id(1) in jail. Emulation or ABI 
> wrong.

This is due to the ABI breakage - your older kernel cannot run the newer
binary from the jail.  The solution is to upgrade your host system past
r318736.  Be sure to follow the proper (and normal) upgrade procedure as
documented in UPDATING.
(For people finding this error on Google, it can indicate anything wrong
in the jail that is disallowing binaries from running from a broken QEMU
to a non-forward-compatible ABI change to simply missing files or broke
jail setup)

Lastly, Poudriere normally automatically rebuilds packages for head
jails anytime the VCS revision is changed, so SVN revision or GIT hash.
This is important in these ABI-breaking cases as you want all packages
to use the new ABI.  I am changing this in the next Poudriere updates to
track __FreeBSD_version for svn/git/-m src= builds.  It will still
continue to track "Release name" for other methods.  This will do 2 things:
1. Rebuild less often and only when someone updates __FreeBSD_version.
This is more proper and we should strive to update this only as needed
to rebuild things.
2. Fix -m src= *not* rebuilding packages after the recent ABI breakage.
If your jail uses -m src= I recommend forcifully doing a bulk -c once to
ensure you get working packages.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature