SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
4.14.13 built, installed and booted, using latest (20180108) intel microcode package. Only been up a few minutes, so I can't report much more than "it boots ok" at present.
I am now running 4.4.111 + intel-ucode 2017-01-08 ( microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16 ) on my Skylake i7 6700K Laptop.
Like GazL, I can report that it booted fine
Below my sig is is interesting commit note from the 4.4.111 ChangeLog.
While the commit references an issue with KDE, the fix is actually an improvement for /proc/vmstat so it may help everybody.
I imagine there will be more improvements like this one in the next few weeks / months.
-- kjh
Code:
commit 90191f71d74901ff88cd10039c03b98ca8a66c08
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri Oct 7 17:02:14 2016 -0700
proc: much faster /proc/vmstat
commit 68ba0326b4e14988f9e0c24a6e12a85cf2acd1ca upstream.
Every current KDE system has process named ksysguardd polling files
below once in several seconds:
$ strace -e trace=open -p $(pidof ksysguardd)
Process 1812 attached
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 8
open("/proc/net/dev", O_RDONLY) = 8
open("/proc/net/wireless", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/stat", O_RDONLY) = 8
open("/proc/vmstat", O_RDONLY) = 8
Hell knows what it is doing but speed up reading /proc/vmstat by 33%!
Benchmark is open+read+close 1.000.000 times.
BEFORE
$ perf stat -r 10 taskset -c 3 ./proc-vmstat
Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):
13146.768464 task-clock (msec) # 0.960 CPUs utilized ( +- 0.60% )
15 context-switches # 0.001 K/sec ( +- 1.41% )
1 cpu-migrations # 0.000 K/sec ( +- 11.11% )
104 page-faults # 0.008 K/sec ( +- 0.57% )
45,489,799,349 cycles # 3.460 GHz ( +- 0.03% )
9,970,175,743 stalled-cycles-frontend # 21.92% frontend cycles idle ( +- 0.10% )
2,800,298,015 stalled-cycles-backend # 6.16% backend cycles idle ( +- 0.32% )
79,241,190,850 instructions # 1.74 insn per cycle
# 0.13 stalled cycles per insn ( +- 0.00% )
17,616,096,146 branches # 1339.956 M/sec ( +- 0.00% )
176,106,232 branch-misses # 1.00% of all branches ( +- 0.18% )
13.691078109 seconds time elapsed ( +- 0.03% )
^^^^^^^^^^^^
AFTER
$ perf stat -r 10 taskset -c 3 ./proc-vmstat
Performance counter stats for 'taskset -c 3 ./proc-vmstat' (10 runs):
8688.353749 task-clock (msec) # 0.950 CPUs utilized ( +- 1.25% )
10 context-switches # 0.001 K/sec ( +- 2.13% )
1 cpu-migrations # 0.000 K/sec
104 page-faults # 0.012 K/sec ( +- 0.56% )
30,384,010,730 cycles # 3.497 GHz ( +- 0.07% )
12,296,259,407 stalled-cycles-frontend # 40.47% frontend cycles idle ( +- 0.13% )
3,370,668,651 stalled-cycles-backend # 11.09% backend cycles idle ( +- 0.69% )
28,969,052,879 instructions # 0.95 insn per cycle
# 0.42 stalled cycles per insn ( +- 0.01% )
6,308,245,891 branches # 726.058 M/sec ( +- 0.00% )
214,685,502 branch-misses # 3.40% of all branches ( +- 0.26% )
9.146081052 seconds time elapsed ( +- 0.07% )
^^^^^^^^^^^
vsnprintf() is slow because:
1. format_decode() is busy looking for format specifier: 2 branches
per character (not in this case, but in others)
2. approximately million branches while parsing format mini language
and everywhere
3. just look at what string() does /proc/vmstat is good case because
most of its content are strings
Link: http://lkml.kernel.org/r/20160806125455.GA1187@p183.telecom.by
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Question:
since I do not have Slackware kernel installed, I wonder if CONFIG_BPF_JIT is disabled (this mitigates partially ver 1 on both intel and AMD)?
Question:
since I do not have Slackware kernel installed, I wonder if CONFIG_BPF_JIT is disabled (this mitigates partially ver 1 on both intel and AMD)?
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
Originally Posted by Didier Spaier
Try this:
Code:
zgrep BPF_JIT /proc/config.gz
I know how to check for BPF_JIT (I am using custom kernels) and I have it disabled.
That is not my question:
Since default kernel from kernel.org has BPF_JIT enabled, I wonder if Slackware kernel has BPF_JIT disabled or not? I do not have Slackware kernel installed so I can't check JIT status.
Question:
since I do not have Slackware kernel installed, I wonder if CONFIG_BPF_JIT is disabled (this mitigates partially ver 1 on both intel and AMD)?
I know how to check for BPF_JIT (I am using custom kernels) and I have it disabled.
That is not my question:
Since default kernel from kernel.org has BPF_JIT enabled, I wonder if Slackware kernel has BPF_JIT disabled or not? I do not have Slackware kernel installed so I can't check JIT status.
I know how to check for BPF_JIT (I am using custom kernels) and I have it disabled.
That is not my question:
Since default kernel from kernel.org has BPF_JIT enabled, I wonder if Slackware kernel has BPF_JIT disabled or not? I do not have Slackware kernel installed so I can't check JIT status.
It's easy to check Slackware's kernel configs on your favorite mirror
In other hand, looks like our BDFL should decide either he ships "hacker level kernels" or at least some solid secured desktop ones.
CONFIG_BPF_JIT may accelerate the packet sniffing, but in other hand, simplify the life of those who try to speculate the Spectre.
Long story short, I think Mr. Robot and his friends knows well how to build their custom sniffing kernels, but for the rookies who just want to browse the net with Firefox, could be problematic to customize and secure their kernels.
Last edited by Darth Vader; 01-12-2018 at 03:26 PM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
Originally Posted by Darth Vader
In other hand, looks like our BDFL should decide either he ships "hacker level kernels" or at least some solid secured desktop ones.
CONFIG_BPF_JIT may accelerate the packet sniffing, but in other hand, simplify the life of those who try to speculate the Spectre.
Long story short, I think Mr. Robot and his friends knows how to build their custom sniffing kernels, but for the rookies who just want to browse the net with Firefox, could be problematic to customize and secure his kernels.
Question:
since I do not have Slackware kernel installed, I wonder if CONFIG_BPF_JIT is disabled (this mitigates partially ver 1 on both intel and AMD)?
Actually it is just the opposite of what you state. The BPF_JIT wants to be enabled to slow down any hackers, because it enables JIT processing exclusively. See https://github.com/torvalds/linux/co...9107da031705cb
Cheers
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
Originally Posted by bamunds
Actually it is just the opposite of what you state. The BPF_JIT wants to be enabled to slow down any hackers, because it enables JIT processing exclusively. See https://github.com/torvalds/linux/co...9107da031705cb
Cheers
Unlike classic BPF, eBPF has data types like data arrays and function pointer arrays into which eBPF bytecode can index. Therefore, it is possible to create the code pattern described above in the kernel using eBPF bytecode.
eBPF's data arrays are less efficient than its function pointer arrays, so the attack will use the latter where possible.
you can disable BPF and leave EBPF
edited:
actually you should disable BPF (AMD)
and leave eBPF on
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
