Steffen Nurpmeso wrote:
> This thread reminds me of me turning off hyperthreading.
> Using the four cores i have with HT turned on results in a 40
> percent time penalty compared to when its off. (For example,
> compiling the Linux kernel 4.19.X takes almost exactly 10 minutes
> when it is turned
Andreas Gustafsson wrote in <24014.56871.750141.885...@guava.gson.org>:
|Jaromír Doleček wrote:
|> I wonder also if we could try enabling vm.ubc_direct on the build \
|> machine?
|
|Using 2019.11.14.13.58.22 sources:
|
|with default settings:
|4612.56 real 16896.10 user 9325.87 sys
Mateusz Guzik wrote:
> > http://www.gson.org/netbsd/bugs/system-time/fg.svg
>
> First thing which jumps at me is DIAGNOSTIC being on (seen with e.g.,
> _vstate_assert). Did your older kernels have it? If you just compiled
> GENERIC from release branches it is presumably removed, so would be
> ni
Jaromír Doleček wrote:
> I wonder also if we could try enabling vm.ubc_direct on the build machine?
Using 2019.11.14.13.58.22 sources:
with default settings:
4612.56 real 16896.10 user 9325.87 sys
with vm.ubc_direct = 1:
4615.95 real 16819.96 user 9416.13 sys
--
Andreas Gusta
Please un-CC me from any threads.
On 11/15/19, Andreas Gustafsson wrote:
> Mateusz Guzik wrote:
>> Can you get a kernel-side flamegraph?
>
> Done, using sources from 2019.11.14.13.58.22:
>
> http://www.gson.org/netbsd/bugs/system-time/fg.svg
>
Thanks.
First thing which jumps at me is DIAGNOSTIC being on (seen with e.g.,
_vstat
Mateusz Guzik wrote:
> Can you get a kernel-side flamegraph?
Done, using sources from 2019.11.14.13.58.22:
http://www.gson.org/netbsd/bugs/system-time/fg.svg
--
Andreas Gustafsson, g...@gson.org
Michael van Elst wrote:
> g...@gson.org (Andreas Gustafsson) writes:
>
> >mitigations, which I guess is not really surprising. But the 12% net
> >increase from jemalloc and the 7% increase from vfs_vnode.c 1.63 seem
> >to call for closer investigation.
>
> Is this also reflected in real time?
O
This is awesome - I know it took a lot of work (your section on bisection
briefly alluded to that), so thanks for doing all of this - very, very
useful
On Thu, 14 Nov 2019 at 11:27, Andreas Gustafsson wrote:
>
> Hi all,
>
> Back in September, I wrote:
> > I'm trying to run a bisection to determi
Le jeu. 14 nov. 2019 à 21:41, Christos Zoulas a
écrit :
> In article <24013.43646.552099.15...@guava.gson.org>,
> Andreas Gustafsson wrote:
> >
> >Hi all,
> >
> >Back in September, I wrote:
>
> > 12% increase:
> >
> >2019.03.08.20.35.10 christos src/share/mk/bsd.own.mk 1.1108
> >
> >Ba
On 11/14/19, Andreas Gustafsson wrote:
>
> Hi all,
>
> Back in September, I wrote:
>> I'm trying to run a bisection to determine why builds hosted on recent
>> versions of NetBSD seem to be taking significantly more system time
>> than they used to, building the same thing.
>
> I finally have some
g...@gson.org (Andreas Gustafsson) writes:
>mitigations, which I guess is not really surprising. But the 12% net
>increase from jemalloc and the 7% increase from vfs_vnode.c 1.63 seem
>to call for closer investigation.
Is this also reflected in real time?
--
--
In article <20191114200928.ga2...@homeworld.netbsd.org>,
wrote:
>On Thu, Nov 14, 2019 at 09:26:54PM +0200, Andreas Gustafsson wrote:
>> 12% increase:
>>
>> 2019.03.08.20.35.10 christos src/share/mk/bsd.own.mk 1.1108
>>
>> Back to using jemalloc for x86_64; all problems have been resol
In article <24013.43646.552099.15...@guava.gson.org>,
Andreas Gustafsson wrote:
>
>Hi all,
>
>Back in September, I wrote:
> 12% increase:
>
>2019.03.08.20.35.10 christos src/share/mk/bsd.own.mk 1.1108
>
>Back to using jemalloc for x86_64; all problems have been resolved.
Indeed I would
On Thu, Nov 14, 2019 at 09:26:54PM +0200, Andreas Gustafsson wrote:
> 12% increase:
>
> 2019.03.08.20.35.10 christos src/share/mk/bsd.own.mk 1.1108
>
> Back to using jemalloc for x86_64; all problems have been resolved.
I wonder if enabling back MAP_ALIGNED in jemalloc can help.
http:/
Hi all,
Back in September, I wrote:
> I'm trying to run a bisection to determine why builds hosted on recent
> versions of NetBSD seem to be taking significantly more system time
> than they used to, building the same thing.
I finally have some results to report. These are from builds of the
N
16 matches
Mail list logo