Franco Martelli, on 2019-08-16:
> On 16/08/19 at 17:22, Étienne Mollier wrote:
[...]
> > Compilers may have good optimization routines to boost the speed
> > of the code in several situations, but in other ones there are
> > trade-offs to take between size and performance of the code. I
> > personally prefer smaller sized executables (-Os): they fit in
> > less pages, so uses less CPU cache, and leave more room for my
> > programs to get more of their own data in cache (or I might
> > simply have spent too much time on suckless.org. ;)
>
> Do you remember which kernel CONFIG switch lets to do this optimization?
You can set these values as following if you want to optimize
for size, or the other way around for performance:
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
Then "make oldconfig" to validate your changes. And same as
before, do your own measures. ;)
> > Activating CPU specific options is interesting on some
> > particular use cases, but newer instruction often require
> > setting up various bits in the CPU before use, which tends to
> > inflate the resulting executable. This may be interesting for
> > scientific applications, or programs dealing with big data
> > arrays in general. In kernel mode however, the only case I can
> > think of where CPU specific accelerators would be beneficial are
> > disk ciphering and RAID arrays, for which I believe there is
> > already some runtime detection of available instructions, even
> > with the generic compiler options.
>
> I have four disks in a RAID 5 software array configuration on my system,
> they are managed by mdadm this is my /proc/mdstat file:
>
> $ cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
> md0 : active raid5 sda1[0] sdb1[1] sdd1[3](S) sdc1[2]
> 1953258496 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
> [UUU]
>
> unused devices: <none>
If you have a look at "sudo dmesg" output, near the beginning,
the kernel outputs a series of performance testing out of
various RAID topologies, and keeps the best for runtime. I'm
speaking from memory, as I have no RAID array at hand to check
this.
[...]
> > Or just see how perform your usual programs, if there are
> > visible improvements.
> >
> > Have fun, :)
>
> Yes I agree the optimization won't impact on performance in a way that
> is perceptively by an human there are tweak more important in the kernel
> such as CONFIG_HZ_1000=y
> I always take measurement of the time employee by kernel compilation out
> of curiosity.
> Thanks again for the tips, best regards
You're welcome, :)
--
Étienne Mollier <etienne.mollier@mailoo.org>
5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Attachment:
signature.asc
Description: OpenPGP digital signature