From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2015-12-23 22:57:59
Please don't continue reading before christmas eve (or morning,
depending on your schedule). If you don't celebrate christmas,
well go ahead.
Dear RT folks!
I'm pleased to announce the v4.4-rc6-rt1 patch set. I tested it on my
AMD A10, 64bit. Nothing exploded so far, filesystem is still there.
I haven't tested it on anything else. Before someone asks: this does not
mean it does *not* work on ARM I simply did not try it.
If you are brave then download it, install it and have fun. If something
breaks, please report it. If your machine starts blinking like a
christmas tree while using the patch then *please* send a photo.
Changes since v4.1.15-rt17:
- rebase to v4.4-rc6
Known issues (inherited from v4.1-RT):
- bcache stays disabled
- CPU hotplug is not better than before
- The netlink_release() OOPS, reported by Clark, is still on the
list, but unsolved due to lack of information
- Christoph Mathys reported a stall in cgroup locking code while using
Linux containers.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v4.4-rc6-rt1
The RT patch against 4.4-rc6 can be found here:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4-rc6-rt1.patch.xz
The split quilt queue is available at:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patches-4.4-rc6-rt1.tar.xz
Sebastian
From: Clark Williams <hidden> Date: 2015-12-31 16:24:52
On Wed, 23 Dec 2015 23:57:55 +0100
Sebastian Andrzej Siewior [off-list ref] wrote:
Please don't continue reading before christmas eve (or morning,
depending on your schedule). If you don't celebrate christmas,
well go ahead.
Dear RT folks!
I'm pleased to announce the v4.4-rc6-rt1 patch set. I tested it on my
AMD A10, 64bit. Nothing exploded so far, filesystem is still there.
I haven't tested it on anything else. Before someone asks: this does not
mean it does *not* work on ARM I simply did not try it.
If you are brave then download it, install it and have fun. If something
breaks, please report it. If your machine starts blinking like a
christmas tree while using the patch then *please* send a photo.
Changes since v4.1.15-rt17:
- rebase to v4.4-rc6
Known issues (inherited from v4.1-RT):
- bcache stays disabled
- CPU hotplug is not better than before
- The netlink_release() OOPS, reported by Clark, is still on the
list, but unsolved due to lack of information
- Christoph Mathys reported a stall in cgroup locking code while using
Linux containers.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v4.4-rc6-rt1
The RT patch against 4.4-rc6 can be found here:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4-rc6-rt1.patch.xz
The split quilt queue is available at:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patches-4.4-rc6-rt1.tar.xz
Sebastian
I pulled this update and tried it on my laptop (i7 quad-core with HT) and an Atom testbox. I'm seeing a change in the cpu utilization of ksoftirqd between 4.1.15-rt17 and 4.4-rc2-rt1, where the per-cpu ksoftirqd threads are running at between 25-40% utilization:
top - 10:15:57 up 13:46, 2 users, load average: 9.44, 9.30, 8.93
Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.7 us, 53.6 sy, 0.0 ni, 37.4 id, 0.1 wa, 0.0 hi, 4.2 si, 0.0 st
KiB Mem : 4046064 total, 480548 free, 179528 used, 3385988 buff/cache
KiB Swap: 5177340 total, 5169908 free, 7432 used. 3785624 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
This is on an otherwise idle box (I had just stopped a kernel compile, hence the load average figures). Normally with my config I see between 2-3% utilization from the ksoftirqd threads.
I've done a small amount of digging and nothing obvious has jumped out at me. Nothing changed in softirq.c, but there were changes in smpboot.c. I've attached the config I used with the 4.4 build.
I'll see what kind of info I can get with ftracing softirq events.
Clark
From: Mike Galbraith <hidden> Date: 2016-01-01 07:19:51
On Thu, 2015-12-31 at 10:24 -0600, Clark Williams wrote:
I pulled this update and tried it on my laptop (i7 quad-core with HT)
and an Atom testbox. I'm seeing a change in the cpu utilization of
ksoftirqd between 4.1.15-rt17 and 4.4-rc2-rt1, where the per-cpu
ksoftirqd threads are running at between 25-40% utilization:
top - 10:15:57 up 13:46, 2 users, load average: 9.44, 9.30, 8.93
Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.7 us, 53.6 sy, 0.0 ni, 37.4 id, 0.1 wa, 0.0 hi, 4.2 si, 0.0 st
KiB Mem : 4046064 total, 480548 free, 179528 used, 3385988 buff/cache
KiB Swap: 5177340 total, 5169908 free, 7432 used. 3785624 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
From: Thomas Gleixner <hidden> Date: 2016-01-01 09:16:19
On Fri, 1 Jan 2016, Mike Galbraith wrote:
On Thu, 2015-12-31 at 10:24 -0600, Clark Williams wrote:
quoted
I pulled this update and tried it on my laptop (i7 quad-core with HT)
and an Atom testbox. I'm seeing a change in the cpu utilization of
ksoftirqd between 4.1.15-rt17 and 4.4-rc2-rt1, where the per-cpu
ksoftirqd threads are running at between 25-40% utilization:
top - 10:15:57 up 13:46, 2 users, load average: 9.44, 9.30, 8.93
Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.7 us, 53.6 sy, 0.0 ni, 37.4 id, 0.1 wa, 0.0 hi, 4.2 si, 0.0 st
KiB Mem : 4046064 total, 480548 free, 179528 used, 3385988 buff/cache
KiB Swap: 5177340 total, 5169908 free, 7432 used. 3785624 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
Heh, I didn't notice immediately because I throttle nohz, am seeing
only tiny utilization (but nohz idle isn't working). With throttle
patch removed, box is screaming, expires=4294990471 pokes eyeball.
swapper 0 [003] 392.708321: timer:hrtimer_cancel: hrtimer=0xffff88041ecce720
swapper 0 [003] 392.708321: timer:hrtimer_start: hrtimer=0xffff88041ecce720 function=tick_sched_timer/0x0 expires=4294990471 softexpires=4294990471
There is a major hickup in the hrtimer RT conversion. I'll have a look next
week.
Thanks,
tglx
From: Mike Galbraith <hidden> Date: 2016-01-01 09:45:53
On Fri, 2016-01-01 at 10:14 +0100, Thomas Gleixner wrote:
On Fri, 1 Jan 2016, Mike Galbraith wrote:
quoted
On Thu, 2015-12-31 at 10:24 -0600, Clark Williams wrote:
quoted
I pulled this update and tried it on my laptop (i7 quad-core with HT)
and an Atom testbox. I'm seeing a change in the cpu utilization of
ksoftirqd between 4.1.15-rt17 and 4.4-rc2-rt1, where the per-cpu
ksoftirqd threads are running at between 25-40% utilization:
top - 10:15:57 up 13:46, 2 users, load average: 9.44, 9.30, 8.93
Tasks: 188 total, 2 running, 186 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.7 us, 53.6 sy, 0.0 ni, 37.4 id, 0.1 wa, 0.0 hi, 4.2 si, 0.0 st
KiB Mem : 4046064 total, 480548 free, 179528 used, 3385988 buff/cache
KiB Swap: 5177340 total, 5169908 free, 7432 used. 3785624 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
Heh, I didn't notice immediately because I throttle nohz, am seeing
only tiny utilization (but nohz idle isn't working). With throttle
patch removed, box is screaming, expires=4294990471 pokes eyeball.
swapper 0 [003] 392.708321: timer:hrtimer_cancel: hrtimer=0xffff88041ecce720
swapper 0 [003] 392.708321: timer:hrtimer_start: hrtimer=0xffff88041ecce720 function=tick_sched_timer/0x0 expires=4294990471 softexpires=4294990471
There is a major hickup in the hrtimer RT conversion. I'll have a look next
week.
Yeah, fixing up the screaming didn't do wonderful things, box is a
lethargic slug. I'll have a poke over the weekend, see how close I get
to fixing hickups up properly.
-Mike
From: Tim Sander <hidden> Date: 2016-01-07 12:15:39
Hi Sebastian
Thanks for your christmas present :-).
Am Mittwoch, 23. Dezember 2015, 23:57:55 schrieb Sebastian Andrzej Siewior:
Please don't continue reading before christmas eve (or morning,
depending on your schedule). If you don't celebrate christmas,
well go ahead.
Ok, i have to admit i am a little late to the party.
Dear RT folks!
I'm pleased to announce the v4.4-rc6-rt1 patch set. I tested it on my
AMD A10, 64bit. Nothing exploded so far, filesystem is still there.
I haven't tested it on anything else. Before someone asks: this does not
mean it does *not* work on ARM I simply did not try it.
With the trivial compile patch below it is working on ARM:
Specifically two Cortex A9 on a CycloneV from Altera.
The performance without load looks good:
# Total: 100000000 100000000
# Min Latencies: 00009 00009
# Avg Latencies: 00010 00010
# Max Latencies: 00022 00033
A short run with hackbench load reveals an latency "island" from 54-69µs on the first core.
There are no timer ticks with 34 to 53 µs delay.
# Total: 001000000 000999714
# Min Latencies: 00010 00009
# Avg Latencies: 00017 00010
# Max Latencies: 00069 00029
I will test further and report if i find strange occurences.
If you are brave then download it, install it and have fun. If something
breaks, please report it. If your machine starts blinking like a
christmas tree while using the patch then *please* send a photo.
Sorry no photos, no special blinking.
Best regards
Tim
Signed-off-by: Tim Sander <redacted>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2016-01-13 17:58:48
* Mike Galbraith | 2016-01-01 08:19:41 [+0100]:
quoted
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
Heh, I didn't notice immediately because I throttle nohz, am seeing
only tiny utilization (but nohz idle isn't working). With throttle
patch removed, box is screaming, expires=4294990471 pokes eyeball.
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
Sebastian
On 01/13/2016 07:58 PM, Sebastian Andrzej Siewior wrote:
* Mike Galbraith | 2016-01-01 08:19:41 [+0100]:
quoted
quoted
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0 307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0 308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0 308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0 222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2 0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1 0:00.39 top
Heh, I didn't notice immediately because I throttle nohz, am seeing
only tiny utilization (but nohz idle isn't working). With throttle
patch removed, box is screaming, expires=4294990471 pokes eyeball.
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
I might be wrong completely, but could below two patches affect on
CPU utilization of ksoftirqd?
6047967 ksoftirqd: Use new cond_resched_rcu_qs() function
28423ad ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
above two patches are not applied on -RT part of softirqs processing.
static void run_ksoftirqd(unsigned int cpu)
{
local_irq_disable();
current->softirq_nestcnt++;
do_current_softirqs();
current->softirq_nestcnt--;
rcu_note_context_switch();
^^^ IRQs disabled
local_irq_enable();
}
--
regards,
-grygorii
From: Mike Galbraith <hidden> Date: 2016-01-14 09:33:27
On Wed, 2016-01-13 at 18:58 +0100, Sebastian Andrzej Siewior wrote:
* Mike Galbraith | 2016-01-01 08:19:41 [+0100]:
quoted
quoted
PID USER PR NI VIRT RES SHR S %CPU %MEM
TIME+ COMMAND
3 root -2 0 0 0 0 S 37.3 0.0
307:52.44 ksoftirqd/0
32 root -2 0 0 0 0 S 37.3 0.0
308:08.72 ksoftirqd/2
42 root -2 0 0 0 0 R 37.3 0.0
308:32.84 ksoftirqd/3
22 root -2 0 0 0 0 S 26.9 0.0
222:29.82 ksoftirqd/1
1 root 20 0 46628 6980 4976 S 1.3 0.2
0:13.98 systemd
22358 williams 20 0 159980 4552 3780 R 1.0 0.1
0:00.39 top
Heh, I didn't notice immediately because I throttle nohz, am seeing
only tiny utilization (but nohz idle isn't working). With throttle
patch removed, box is screaming, expires=4294990471 pokes eyeball.
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode
has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
Thomas said the hrtimer adjustments went a little out of round. I
started rummaging, but then the world woke up from the holidays, so I
didn't get _to_ square one, much lest past it. Hohum.
-Mike
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2016-01-14 14:17:48
* Sebastian Andrzej Siewior | 2016-01-13 18:58:45 [+0100]:
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
From: Mike Galbraith <hidden> Date: 2016-01-14 14:31:50
On Thu, 2016-01-14 at 15:17 +0100, Sebastian Andrzej Siewior wrote:
quoted hunk
* Sebastian Andrzej Siewior | 2016-01-13 18:58:45 [+0100]:
quoted
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode
has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
@@ -1453,7 +1453,7 @@ u64 get_next_timer_interrupt(unsigned long
basej, u64 basem)
* the base lock to check when the next timer is pending and
so
* we assume the next jiffy.
*/
- return basej;
+ return basem + TICK_NSEC;
#endif
spin_lock(&base->lock);
if (base->active_timers) {
That's what I had done to stop the screaming interrupt, but box still
behaved very badly.
-Mike
From: Thomas Gleixner <hidden> Date: 2016-01-14 14:32:09
On Thu, 14 Jan 2016, Mike Galbraith wrote:
On Thu, 2016-01-14 at 15:17 +0100, Sebastian Andrzej Siewior wrote:
quoted
* Sebastian Andrzej Siewior | 2016-01-13 18:58:45 [+0100]:
quoted
This is due to NO_HZ as far as I can tell. My AMD A10 in idle mode
has
0.7% utilisation of ksoftirqd/ with CONFIG_HZ_PERIODIC and with
CONFIG_NO_HZ_FULL it shows about 25% on all CPU threads.
@@ -1453,7 +1453,7 @@ u64 get_next_timer_interrupt(unsigned long
basej, u64 basem)
* the base lock to check when the next timer is pending and
so
* we assume the next jiffy.
*/
- return basej;
+ return basem + TICK_NSEC;
#endif
spin_lock(&base->lock);
if (base->active_timers) {
That's what I had done to stop the screaming interrupt, but box still
behaved very badly.
If you turn off CONFIG_NO_HZ_FULL and switch to NO_HZ_IDLE is it still bad?
Thanks,
tglx
@@ -1453,7 +1453,7 @@ u64 get_next_timer_interrupt(unsigned long
basej, u64 basem)
* the base lock to check when the next timer is pending and
so
* we assume the next jiffy.
*/
- return basej;
+ return basem + TICK_NSEC;
#endif
spin_lock(&base->lock);
if (base->active_timers) {
That's what I had done to stop the screaming interrupt, but box
still
quoted
behaved very badly.
If you turn off CONFIG_NO_HZ_FULL and switch to NO_HZ_IDLE is it
still bad?
I didn't have CONFIG_NO_HZ_FULL enabled, it was CONFIG_NO_HZ_IDLE.
-Mike
I might be wrong completely, but could below two patches affect on
CPU utilization of ksoftirqd?
6047967 ksoftirqd: Use new cond_resched_rcu_qs() function
28423ad ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
above two patches are not applied on -RT part of softirqs processing.
@@ -1453,7 +1453,7 @@ u64 get_next_timer_interrupt(unsigned long
basej, u64 basem)
* the base lock to check when the next timer is pending and
so
* we assume the next jiffy.
*/
- return basej;
+ return basem + TICK_NSEC;
#endif
spin_lock(&base->lock);
if (base->active_timers) {
That's what I had done to stop the screaming interrupt, but box
still
quoted
behaved very badly.
If you turn off CONFIG_NO_HZ_FULL and switch to NO_HZ_IDLE is it
still bad?
I didn't have CONFIG_NO_HZ_FULL enabled, it was CONFIG_NO_HZ_IDLE.
So with the above fix it still behaves badly. Can you provide your config and
a hint which workload/idle/whatever state results in bad behaviour.
Thanks,
tglx
From: Mike Galbraith <hidden> Date: 2016-01-16 13:23:29
On Thu, 2016-01-14 at 17:05 +0100, Mike Galbraith wrote:
This is virgin -rt1 modulo fixlet applied to v4.4.0, built with the
.config from v4.4.0 that built it (modulo RT_FULL) rebuilding itself
via make -j8.
homer:/root # vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 14742988 179832 680792 0 0 634 25 326 1196 2 1 89 8 0
8 0 0 14476084 179848 701632 0 0 814 525 2421 12314 11 1 87 1 0
8 0 0 14483232 179864 712656 0 0 165 1628 2404 12320 11 1 87 1 0
8 0 0 14493336 180008 727836 0 0 141 762 2328 11306 11 1 87 0 0
8 0 0 14456436 180024 738356 0 0 159 1478 2336 11939 11 1 87 0 0
Way too idle, taking forever.
It now being the weekend...
sched: Disable default set_cpus_allowed() method during update_migrate_disable().
update_migrate_disable() calls class::set_cpus_allowed(), when that method
is set_cpus_allowed_common(), writing to ->cpus_allowed defeats the intent
of migrate_disable(), permanently disabling migration instead.
Signed-off-by: Mike Galbraith <redacted>
---
kernel/sched/core.c | 2 ++
1 file changed, 2 insertions(+)
From: Thomas Gleixner <hidden> Date: 2016-01-16 13:44:39
On Sat, 16 Jan 2016, Mike Galbraith wrote:
On Thu, 2016-01-14 at 17:05 +0100, Mike Galbraith wrote:
quoted
This is virgin -rt1 modulo fixlet applied to v4.4.0, built with the
.config from v4.4.0 that built it (modulo RT_FULL) rebuilding itself
via make -j8.
homer:/root # vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 14742988 179832 680792 0 0 634 25 326 1196 2 1 89 8 0
8 0 0 14476084 179848 701632 0 0 814 525 2421 12314 11 1 87 1 0
8 0 0 14483232 179864 712656 0 0 165 1628 2404 12320 11 1 87 1 0
8 0 0 14493336 180008 727836 0 0 141 762 2328 11306 11 1 87 0 0
8 0 0 14456436 180024 738356 0 0 159 1478 2336 11939 11 1 87 0 0
Way too idle, taking forever.
It now being the weekend...
sched: Disable default set_cpus_allowed() method during update_migrate_disable().
update_migrate_disable() calls class::set_cpus_allowed(), when that method
is set_cpus_allowed_common(), writing to ->cpus_allowed defeats the intent
of migrate_disable(), permanently disabling migration instead.
From: Thomas Gleixner <hidden> Date: 2016-01-16 14:00:50
On Sat, 16 Jan 2016, Mike Galbraith wrote:
On Sat, 2016-01-16 at 14:43 +0100, Thomas Gleixner wrote:
quoted
Ha, you found it as well :)
Yeah, with time to actually look, I rather quickly had one of those
"well _duh_" moments :)
Actually the new way how the scheduler handles set_cpus_allowed() makes it
superflous to call that stuff at all.
All scheduler classes except deadline merily call set_cpus_allowed_common()
and deadline does not do the 'change root domain' dance either.
So we can simplify the whole business a lot.
Thanks,
tglx
From: Mike Galbraith <hidden> Date: 2016-01-16 14:09:34
On Sat, 2016-01-16 at 14:59 +0100, Thomas Gleixner wrote:
All scheduler classes except deadline merily call set_cpus_allowed_common()
and deadline does not do the 'change root domain' dance either.
So we can simplify the whole business a lot.
Goody. Seeing if I could avoid mostly useless function call was next.
On 12/24/2015 12:57 AM, Sebastian Andrzej Siewior wrote:
Please don't continue reading before christmas eve (or morning,
depending on your schedule). If you don't celebrate christmas,
well go ahead.
Dear RT folks!
I'm pleased to announce the v4.4-rc6-rt1 patch set. I tested it on my
AMD A10, 64bit. Nothing exploded so far, filesystem is still there.
I haven't tested it on anything else. Before someone asks: this does not
mean it does *not* work on ARM I simply did not try it.
If you are brave then download it, install it and have fun. If something
breaks, please report it. If your machine starts blinking like a
christmas tree while using the patch then *please* send a photo.
Changes since v4.1.15-rt17:
- rebase to v4.4-rc6
Known issues (inherited from v4.1-RT):
- bcache stays disabled
- CPU hotplug is not better than before
- The netlink_release() OOPS, reported by Clark, is still on the
list, but unsolved due to lack of information
- Christoph Mathys reported a stall in cgroup locking code while using
Linux containers.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v4.4-rc6-rt1
The RT patch against 4.4-rc6 can be found here:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4-rc6-rt1.patch.xz
The split quilt queue is available at:
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/patches-4.4-rc6-rt1.tar.xz
Additional note: RCU_BOOST now depends on RCU_EXPERT, so commit
3da4cab "rcu: make RCU_BOOST default on RT" is nop now.
config RCU_BOOST
bool "Enable RCU priority boosting"
depends on RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT
default y if PREEMPT_RT_FULL
--
regards,
-grygorii
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2016-01-22 15:48:14
On 01/22/2016 04:35 PM, Grygorii Strashko wrote:
Additional note: RCU_BOOST now depends on RCU_EXPERT, so commit
3da4cab "rcu: make RCU_BOOST default on RT" is nop now.
config RCU_BOOST
bool "Enable RCU priority boosting"
depends on RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT
default y if PREEMPT_RT_FULL
yeah, I've been thinking about giving the experts menu item an y on RT
as well.
Sebastian
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2016-01-22 20:44:14
* Sebastian Andrzej Siewior | 2016-01-22 16:48:09 [+0100]:
On 01/22/2016 04:35 PM, Grygorii Strashko wrote:
quoted
Additional note: RCU_BOOST now depends on RCU_EXPERT, so commit
3da4cab "rcu: make RCU_BOOST default on RT" is nop now.
config RCU_BOOST
bool "Enable RCU priority boosting"
depends on RT_MUTEXES && PREEMPT_RCU && RCU_EXPERT
default y if PREEMPT_RT_FULL
yeah, I've been thinking about giving the experts menu item an y on RT
as well.
Subject: [PATCH] RCU: make RCU_EXPERT y on RT
because we want RCU_BOOST y on RT
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)