Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jul 2013 23:23:31 -0700
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>
Subject:   Re: svn commit: r253002 - head
Message-ID:  <CAGHfRMDmRXR1jTF_CO4T8NXOPW5Soxjrq1y_eb41mKZG2yQiiw@mail.gmail.com>
In-Reply-To: <D3E9FF9F-E53A-40DE-8DFF-C4A4F05566D4@gmail.com>
References:  <201307072039.r67KdCdR028908@svn.freebsd.org> <9D4C7540-A3B0-45E5-8219-6A455D41DF70@gmail.com> <51D9DA55.2090808@freebsd.org> <D3E9FF9F-E53A-40DE-8DFF-C4A4F05566D4@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 7, 2013 at 7:25 PM, Garrett Cooper <yaneurabeya@gmail.com> wrot=
e:
> On Jul 7, 2013, at 2:15 PM, Alfred Perlstein <alfred@freebsd.org> wrote:
>
>> On 7/7/13 2:01 PM, Garrett Cooper wrote:
>>> Why the magic number 12?
>>
>> Numbers higher seem to result in worse performance as reported by some m=
embers of my team.
>
> The suggestion is good in spirit, but this doesn't justify the reasoning =
for this recommendation for all cases.
>
> Please revert this change and add a doc page or notes to the dev handbook=
 discussing what the empirical process and results were for determining thi=
s value so people can come up with their own values that work best with the=
ir hardware and software config. This recommendation is prone to bitrot lik=
e some of the recommendations in tuning(7).
>
> Misinformation is sometimes more harmful than no information.

I spoke with Alfred over the phone and did some more careful thought
about this and I'm rescinding this request.

Alfred did a good job at documenting how JFLAG works (it was
previously undocumented). My concern over -j12 was performance
related, and after giving things more careful thought it actually
makes sense why -j12 was chosen because Westmere and newer processors
have issues with NUMA and cache locality between multiple processor
packages as we've seen non-empirically and empirically at Isilon with
FreeBSD 7 and 10 (it's a known issue that jeffr@ and jhb@ are aware
of).

I'll come up with a concise patch that does what Alfred was trying to
achieve and have Alfred review it.

Thanks (and thank you Alfred for the contribution!!!)!
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMDmRXR1jTF_CO4T8NXOPW5Soxjrq1y_eb41mKZG2yQiiw>