Am Dienstag, den 09.01.2018, 19:36 +0000 schrieb Ken Moffat:
> On Tue, Jan 09, 2018 at 08:13:39AM +0100, Thomas Trepl wrote:
> > Interesting that Intel (https://newsroom.intel.de/news-releases/ind
> > ustr
> > y-testing-shows-recently-released-security-updates-not-impacting-
> > performance-real-world-deployments/) thinks that there is no
> > performance issue.
> > 
> > Meassuring LFS builds looks a bit different to me (column 2+3 are
> > build
> > times in seconds and may not be 100% accurate but the trend is
> > clear):
> > 
> 
> A few questions:
> 
> 1. Is this building the same versions, but just using a different
> kernel ?  Actually, I thought PTI was _perhaps_ available on
> 4.14.10.
Uuh, not that I'm aware of that in .10 the PTI stuff was implemented. 
In that .10-system, "cat /proc/cpuinfo" shows nothing in the "bugs:"
line (while .12 says "bugs: cpu_insecure") and there is nothing about
KPTI in dmesg when booting the .10. 

The test was building a 4.14.12 system on a 4.14.10 and than use the
newly built system to redo the build of that .12. The packages
installed and build are on both versions the same. What column 2 shows
is building .12 on a .10 system, column 3 shows the times when building
the same .12 system using the previously built .12. Starting with one
system (.10) i finally had three systems
1) the .10
2) the .12 built by the .10
3) another .12 built by the .12

The only difference between .10 and .12 was that .10 was based on LFS-
book 20180101 and .12 on 20180106 (beside the kernel version containing
newer version of gdbm and e2fsprogs).

> In general, single builds are anecdotal - I often find that - even
> without obvious background activity (e.g. cron jobs, browser
> activity) a build can vary by a few seconds.
Sure, that is why i said its not 100% accurate and there even is a
package which lasts a few seconds less (ch5-gcc-pass2, ch6-bzip2).
Maybe there was some activitity while building .10 that delayed that
build of the .10-system. If the build varies a few seconds in this or
that direction, then I wouldn't complain, but it seems that over all
packages the picture seems to be clear.

> The ideal would be to repeat the build a few time for both PTI and
> nopti - I don't have time to do that, so I'm not proposing that
> anyone else should, just mentioning that a single time is not
> definitive.
Agreed - should try to do some more builds

> 2. Do you have newer firmware (to mitigate Spectre) ?  That is the
> thing which intel kernel developers think will slow things down.
No, didn't load any CPU firmware, neither for .10 nor for .12. CPU is a
"vanilla" E3-1245.

> 3. For Meltdown (PTI) the main impacted use cases appear to be web
> servers (with lots of network connections), databases, general
> networking throughput on a currently-adequate system.
> 
> For the moment, I'll only comment on one of these -
> 
> > 300-linux-kernel           4079  4654   1,14
This huge number of seconds (good amount over an hour) is because I use
a full-blown config (initially stolen from ArchLinux) including
initramfs. It builds nearly all modules and such - for the sake to my
lacyness stripping down the kernel config to match my hardware.

> That is the sort of thing to make kernel developers go 'ouch!'.
> On my own tests (haswell -j8, SandyBridge -j4) there was very little
> difference with and without PTI.
The increase of build time for the kernel is same as seen for nearly
all other packages (+14%)

All in all, you're right, a single test is not that representative.
I'll try to do some more builds to verify that (thanks to the Xeon E3-
1245 it is not that time consuming).

--
Thomas

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Reply via email to