Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Thu, 2021-11-11 at 10:56 +, Valentin Schneider wrote: > On 11/11/21 11:32, Mike Galbraith wrote: > > On Thu, 2021-11-11 at 10:36 +0100, Marco Elver wrote: > > > I guess the question is if is_preempt_full() should be true also if > > > is_preempt_rt() is true? > > > > That's what CONFIG_PREEMPTION is. More could follow, but it was added > > to allow multiple models to say "preemptible". > > > > That's what I was gonna say, but you can have CONFIG_PREEMPTION while being > is_preempt_none() due to PREEMPT_DYNAMIC... Ah, right.. this is gonna take some getting used to. -Mike
Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Thu, 2021-11-11 at 10:36 +0100, Marco Elver wrote: > On Thu, 11 Nov 2021 at 04:47, Mike Galbraith wrote: > > > > On Thu, 2021-11-11 at 04:35 +0100, Mike Galbraith wrote: > > > On Thu, 2021-11-11 at 04:16 +0100, Mike Galbraith wrote: > > > > On Wed, 2021-11-10 at 20:24 +, Valentin Schneider wrote: > > > > > > > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > > > > index 5f8db54226af..0640d5622496 100644 > > > > > --- a/include/linux/sched.h > > > > > +++ b/include/linux/sched.h > > > > > @@ -2073,6 +2073,22 @@ static inline void cond_resched_rcu(void) > > > > > #endif > > > > > } > > > > > > > > > > +#ifdef CONFIG_PREEMPT_DYNAMIC > > > > > + > > > > > +extern bool is_preempt_none(void); > > > > > +extern bool is_preempt_voluntary(void); > > > > > +extern bool is_preempt_full(void); > > > > > + > > > > > +#else > > > > > + > > > > > +#define is_preempt_none() IS_ENABLED(CONFIG_PREEMPT_NONE) > > > > > +#define is_preempt_voluntary() > > > > > IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) > > > > > +#define is_preempt_full() IS_ENABLED(CONFIG_PREEMPT) > > > > > > > > I think that should be IS_ENABLED(CONFIG_PREEMPTION), see > > > > c1a280b68d4e. > > > > > > > > Noticed while applying the series to an RT tree, where tglx > > > > has done that replacement to the powerpc spot your next patch > > > > diddles. > > > > > > Damn, then comes patch 5 properly differentiating PREEMPT/PREEMPT_RT. > > > > So I suppose the powerpc spot should remain CONFIG_PREEMPT and become > > CONFIG_PREEMPTION when the RT change gets merged, because that spot is > > about full preemptibility, not a distinct preemption model. > > > > That's rather annoying :-/ > > I guess the question is if is_preempt_full() should be true also if > is_preempt_rt() is true? That's what CONFIG_PREEMPTION is. More could follow, but it was added to allow multiple models to say "preemptible". > Not sure all cases are happy with that, e.g. the kernel/trace/trace.c > case, which wants to print the precise preemption level. Yeah, that's the "annoying" bit, needing one oddball model accessor that isn't about a particular model. > To avoid confusion, I'd introduce another helper that says true if the > preemption level is "at least full", currently that'd be "full or rt". > Something like is_preempt_full_or_rt() (but might as well write > "is_preempt_full() || is_preempt_rt()"), or is_preemption() (to match > that Kconfig variable, although it's slightly confusing). The > implementation of that helper can just be a static inline function > returning "is_preempt_full() || is_preempt_rt()". > > Would that help? Yeah, as it sits two accessors are needed, one that says PREEMPT the other PREEMPTION, spelling optional. -Mike
Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Thu, 2021-11-11 at 04:47 +0100, Mike Galbraith wrote: > > So I suppose the powerpc spot should remain CONFIG_PREEMPT and become > CONFIG_PREEMPTION when the RT change gets merged, because that spot is > about full preemptibility, not a distinct preemption model. KCSAN needs a little help to be usable by RT, but ditto that spot. -Mike
Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Thu, 2021-11-11 at 04:35 +0100, Mike Galbraith wrote: > On Thu, 2021-11-11 at 04:16 +0100, Mike Galbraith wrote: > > On Wed, 2021-11-10 at 20:24 +, Valentin Schneider wrote: > > > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > > index 5f8db54226af..0640d5622496 100644 > > > --- a/include/linux/sched.h > > > +++ b/include/linux/sched.h > > > @@ -2073,6 +2073,22 @@ static inline void cond_resched_rcu(void) > > > #endif > > > } > > > > > > +#ifdef CONFIG_PREEMPT_DYNAMIC > > > + > > > +extern bool is_preempt_none(void); > > > +extern bool is_preempt_voluntary(void); > > > +extern bool is_preempt_full(void); > > > + > > > +#else > > > + > > > +#define is_preempt_none() IS_ENABLED(CONFIG_PREEMPT_NONE) > > > +#define is_preempt_voluntary() > > > IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) > > > +#define is_preempt_full() IS_ENABLED(CONFIG_PREEMPT) > > > > I think that should be IS_ENABLED(CONFIG_PREEMPTION), see > > c1a280b68d4e. > > > > Noticed while applying the series to an RT tree, where tglx > > has done that replacement to the powerpc spot your next patch > > diddles. > > Damn, then comes patch 5 properly differentiating PREEMPT/PREEMPT_RT. So I suppose the powerpc spot should remain CONFIG_PREEMPT and become CONFIG_PREEMPTION when the RT change gets merged, because that spot is about full preemptibility, not a distinct preemption model. That's rather annoying :-/ -Mike
Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Thu, 2021-11-11 at 04:16 +0100, Mike Galbraith wrote: > On Wed, 2021-11-10 at 20:24 +, Valentin Schneider wrote: > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index 5f8db54226af..0640d5622496 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -2073,6 +2073,22 @@ static inline void cond_resched_rcu(void) > > #endif > > } > > > > +#ifdef CONFIG_PREEMPT_DYNAMIC > > + > > +extern bool is_preempt_none(void); > > +extern bool is_preempt_voluntary(void); > > +extern bool is_preempt_full(void); > > + > > +#else > > + > > +#define is_preempt_none() IS_ENABLED(CONFIG_PREEMPT_NONE) > > +#define is_preempt_voluntary() > > IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) > > +#define is_preempt_full() IS_ENABLED(CONFIG_PREEMPT) > > I think that should be IS_ENABLED(CONFIG_PREEMPTION), see > c1a280b68d4e. > > Noticed while applying the series to an RT tree, where tglx > has done that replacement to the powerpc spot your next patch > diddles. Damn, then comes patch 5 properly differentiating PREEMPT/PREEMPT_RT. -Mike
Re: [PATCH v2 2/5] preempt/dynamic: Introduce preempt mode accessors
On Wed, 2021-11-10 at 20:24 +, Valentin Schneider wrote: > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 5f8db54226af..0640d5622496 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -2073,6 +2073,22 @@ static inline void cond_resched_rcu(void) > #endif > } > > +#ifdef CONFIG_PREEMPT_DYNAMIC > + > +extern bool is_preempt_none(void); > +extern bool is_preempt_voluntary(void); > +extern bool is_preempt_full(void); > + > +#else > + > +#define is_preempt_none() IS_ENABLED(CONFIG_PREEMPT_NONE) > +#define is_preempt_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) > +#define is_preempt_full() IS_ENABLED(CONFIG_PREEMPT) I think that should be IS_ENABLED(CONFIG_PREEMPTION), see c1a280b68d4e. Noticed while applying the series to an RT tree, where tglx has done that replacement to the powerpc spot your next patch diddles. -Mike
Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback
On Tue, 2017-08-29 at 20:56 -0400, Jerome Glisse wrote: > On Tue, Aug 29, 2017 at 05:11:24PM -0700, Linus Torvalds wrote: > > > People - *especially* the people who saw issues under KVM - can you > > try out Jérôme's patch-series? I aded some people to the cc, the full > > series is on lkml. Jérôme - do you have a git branch for people to > > test that they could easily pull and try out? > > https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch > git://people.freedesktop.org/~glisse/linux Looks good here. I reproduced fairly quickly with RT host and 1 RT guest by just having the guest do a parallel kbuild over NFS (the guest had to be restored afterward, was corrupted). I'm currently flogging 2 guests as well as the host, whimper free. I'll let the lot broil for while longer, but at this point, smoke/flame appearance seems comfortingly unlikely. -Mike
Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls
On Fri, 2017-02-03 at 14:37 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote: > > FWIW, I'm not seeing stalls/hangs while beating hotplug up in tip. (so > > next grew a wart?) > > I've seen it on tip. It looks like hot unplug goes really slow when > there's running tasks on the CPU being taken down. > > What I did was something like: > > taskset -p $((1<<1)) $$ > for ((i=0; i<20; i++)) do while :; do :; done & done > > taskset -p $((1<<0)) $$ > echo 0 > /sys/devices/system/cpu/cpu1/online > > And with those 20 tasks stuck sucking cycles on CPU1, the unplug goes > _really_ slow and the RCU stall triggers. What I suspect happens is that > hotplug stops participating in the RCU state machine early, but only > tells RCU about it really late, and in between it gets suspicious it > takes too long. Ah. I wasn't doing a really hard pounding, just running a couple instances of Steven's script. To beat hell out of it, I add futextest, stockfish and a small kbuild on a big box. -Mike
Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls
On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote: > > I ran few cycles of cpu hot(un)plug tests. In most cases it works except one > > where I ran into rcu stall: > > > > [ 173.493453] INFO: rcu_sched detected stalls on CPUs/tasks: > > [ 173.493473] > > > > 8-...: (2 GPs behind) idle=006/140/0 > > softirq=0/0 fqs=2996 > > [ 173.493476] > > > > (detected by 0, t=6002 jiffies, g=885, c=884, > > q=6350) > > Right, I actually saw that too, but I don't think that would be related > to my patch. I'll see if I can dig into this though, ought to get fixed > regardless. FWIW, I'm not seeing stalls/hangs while beating hotplug up in tip. (so next grew a wart?) -Mike
Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls
On Thu, 2017-02-02 at 16:55 +0100, Peter Zijlstra wrote: > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote: > > On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith > > wrote: > > > On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > > > Could some of you test this? It seems to cure things in my (very) > limited testing. Hotplug stress gripe is gone here. -Mike
Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls
On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > Trimming the cc list. > > > > I assume I should be worried? > > > > Thanks for the report. No need to worry, the bug has existed for a > > while, this patch just turns on the warning ;-) > > > > The following commit queued up in tip/sched/core should fix your > > issues (assuming you see the same callstack on all your powerpc > > machines): > > > > > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=sched/core&id=1b1d62254df0fe42a711eb71948f915918987790 > > I still see this warning with today’s next running inside PowerVM LPAR > on a POWER8 box. The stack trace is different from what Michael had > reported. > > Easiest way to recreate this is to Online/offline cpu’s. (Ditto tip.today, x86_64 + hotplug stress) [ 94.804196] [ cut here ] [ 94.804201] WARNING: CPU: 3 PID: 27 at kernel/sched/sched.h:804 set_next_entity+0x81c/0x910 [ 94.804201] rq->clock_update_flags < RQCF_ACT_SKIP [ 94.804202] Modules linked in: ebtable_filter(E) ebtables(E) fuse(E) bridge(E) stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) xt_tcpudp(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) ipt_REJECT(E) iptable_raw(E) iptable_filter(E) ip6table_mangle(E) nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) ip6table_filter(E) ip6_tables(E) x_tables(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) nls_iso8859_1(E) crc32c_intel(E) nls_cp437(E) snd_hda_codec_realtek(E) snd_hda_codec_hdmi(E) snd_hda_codec_generic(E) nfsd(E) aesni_intel(E) snd_hda_intel(E) snd_hda_codec(E) snd_hwdep(E) aes_x86_64(E) snd_hda_core(E) crypto_simd(E) [ 94.804220] snd_pcm(E) auth_rpcgss(E) snd_timer(E) snd(E) iTCO_wdt(E) iTCO_vendor_support(E) joydev(E) nfs_acl(E) lpc_ich(E) cryptd(E) lockd(E) intel_smartconnect(E) mfd_core(E) i2c_i801(E) battery(E) glue_helper(E) mei_me(E) shpchp(E) mei(E) soundcore(E) grace(E) fan(E) thermal(E) tpm_infineon(E) pcspkr(E) sunrpc(E) efivarfs(E) sr_mod(E) cdrom(E) hid_logitech_hidpp(E) hid_logitech_dj(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) nouveau(E) wmi(E) i2c_algo_bit(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) ahci(E) xhci_pci(E) ehci_pci(E) ttm(E) libahci(E) xhci_hcd(E) ehci_hcd(E) r8169(E) mii(E) libata(E) drm(E) usbcore(E) fjes(E) video(E) button(E) af_packet(E) sd_mod(E) vfat(E) fat(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mod(E) loop(E) sg(E) scsi_mod(E) autofs4(E) [ 94.804246] CPU: 3 PID: 27 Comm: migration/3 Tainted: GE 4.10.0-tip #15 [ 94.804247] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 [ 94.804247] Call Trace: [ 94.804251] ? dump_stack+0x5c/0x7c [ 94.804253] ? __warn+0xc4/0xe0 [ 94.804255] ? warn_slowpath_fmt+0x4f/0x60 [ 94.804256] ? set_next_entity+0x81c/0x910 [ 94.804258] ? pick_next_task_fair+0x20a/0xa20 [ 94.804259] ? sched_cpu_starting+0x50/0x50 [ 94.804260] ? sched_cpu_dying+0x237/0x280 [ 94.804261] ? sched_cpu_starting+0x50/0x50 [ 94.804262] ? cpuhp_invoke_callback+0x83/0x3e0 [ 94.804263] ? take_cpu_down+0x56/0x90 [ 94.804266] ? multi_cpu_stop+0xa9/0xd0 [ 94.804267] ? cpu_stop_queue_work+0xb0/0xb0 [ 94.804268] ? cpu_stopper_thread+0x81/0x110 [ 94.804270] ? smpboot_thread_fn+0xfe/0x150 [ 94.804272] ? kthread+0xf4/0x130 [ 94.804273] ? sort_range+0x20/0x20 [ 94.804274] ? kthread_park+0x80/0x80 [ 94.804276] ? ret_from_fork+0x26/0x40 [ 94.804277] ---[ end trace b0a9e4aa1fb229bb ]---
Re: [PATCH v3 3/3] sched: BUG when stack end location is over written
On Fri, 2014-09-12 at 10:44 +0100, Aaron Tomlin wrote: > On Fri, Sep 12, 2014 at 02:06:57PM +1000, Michael Ellerman wrote: > > On Thu, 2014-09-11 at 16:41 +0100, Aaron Tomlin wrote: > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > index a285900..2a8280a 100644 > > > --- a/lib/Kconfig.debug > > > +++ b/lib/Kconfig.debug > > > @@ -824,6 +824,18 @@ config SCHEDSTATS > > > application, you can say N to avoid the very slight overhead > > > this adds. > > > > > > +config SCHED_STACK_END_CHECK > > > + bool "Detect stack corruption on calls to schedule()" > > > + depends on DEBUG_KERNEL > > > + default y > > > > Did you really mean default y? > > > > Doing so means it will be turned on more or less everywhere, which defeats > > the > > purpose of having a config option in the first place. > > Only if Kconfig CONFIG_DEBUG_KERNEL is enabled in the first place. Which is likely enabled just about everywhere on the planet. -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_NO_HZ causing poor console responsiveness
On Thu, 2010-07-01 at 16:55 -0500, Timur Tabi wrote:
> On Tue, Jun 29, 2010 at 2:54 PM, Timur Tabi wrote:
> > I'm adding support for a new e500-based board (the P1022DS), and in
> > the process I've discovered that enabling CONFIG_NO_HZ (Tickless
> > System / Dynamic Ticks) causes significant responsiveness problems on
> > the serial console. When I type on the console, I see delays of up to
> > a half-second for almost every character. It acts as if there's a
> > background process eating all the CPU.
>
> I finally finished my git-bisect, and it wasn't that helpful. I had
> to skip several commits because the kernel just wouldn't boot:
>
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 6bc6cf2b61336ed0c55a615eb4c0c8ed5daf3f08
> 8b911acdf08477c059d1c36c21113ab1696c612b
> 21406928afe43f1db6acab4931bb8c886f4d04ce
> 5ca9880c6f4ba4c84b517bc2fed5366adf63d191
> a64692a3afd85fe048551ab89142fd5ca99a0dbd
> f2e74eeac03ffb779d64b66a643c5e598145a28b
> c6ee36c423c3ed1fb86bb3eabba9fc256a300d16
> e12f31d3e5d36328c7fbd0fce40a95e70b59152c
> 13814d42e45dfbe845a0bbe5184565d9236896ae
> b42e0c41a422a212ddea0666d5a3a0e3c35206db
> 39c0cbe2150cbd848a25ba6cdb271d1ad46818ad <== the crime scene
> beac4c7e4a1cc6d57801f690e5e82fa2c9c245c8
> 41acab8851a0408c1d5ad6c21a07456f88b54d40
> 6427462bfa50f50dc6c088c07037264fcc73eca1
> c9494727cf293ae2ec66af57547a3e79c724fec2
> We cannot bisect more!
>
> These correspond to a batch of scheduler patches, most from Mike Galbraith.
>
> I don't know what to do now. I can't test any of these commits. Even
> if I could, they look like they're all part of one set, so I doubt I
> could narrow it down to one commit anyway.
Hi Timur,
This has already fixed. Below is the final fix from tip.
commit 3310d4d38fbc514e7b18bd3b1eea8effdd63b5aa
Author: Peter Zijlstra
Date: Thu Jun 17 18:02:37 2010 +0200
nohz: Fix nohz ratelimit
Chris Wedgwood reports that 39c0cbe (sched: Rate-limit nohz) causes a
serial console regression, unresponsiveness, and indeed it does. The
reason is that the nohz code is skipped even when the tick was already
stopped before the nohz_ratelimit(cpu) condition changed.
Move the nohz_ratelimit() check to the other conditions which prevent
long idle sleeps.
Reported-by: Chris Wedgwood
Tested-by: Brian Bloniarz
Signed-off-by: Mike Galbraith
Signed-off-by: Peter Zijlstra
Cc: Jiri Kosina
Cc: Linus Torvalds
Cc: Greg KH
Cc: Alan Cox
Cc: OGAWA Hirofumi
Cc: Jef Driesen
LKML-Reference: <1276790557.27822.516.ca...@twins>
Signed-off-by: Thomas Gleixner
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 1d7b9bc..783fbad 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -315,9 +315,6 @@ void tick_nohz_stop_sched_tick(int inidle)
goto end;
}
- if (nohz_ratelimit(cpu))
- goto end;
-
ts->idle_calls++;
/* Read jiffies and the time when jiffies were updated last */
do {
@@ -328,7 +325,7 @@ void tick_nohz_stop_sched_tick(int inidle)
} while (read_seqretry(&xtime_lock, seq));
if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
- arch_needs_cpu(cpu)) {
+ arch_needs_cpu(cpu) || nohz_ratelimit(cpu)) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
} else {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
