search for: mwait_idle

1: x86/mwait_idle: remove assumption of one C-state per MWAIT flag 2: x86/mwait_idle: export both C1 and C1E 3: x86/mwait_idle: initial C8, C9, C10 support Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com>

...t guaranteed to be ordered by any other fencing or serializing instructions or by another CLFLUSH instruction. For example, software can use an MFENCE instruction to ensure that previous stores are included in the write-back. There are instances of this in mwait_play_dead, clflush_cache_range, mwait_idle_with_hints, mwait_idle .. A comment near pcommit_sfence includes an example flush_and_commit_buffer code which is interesting - it assumes sfence flushes clflush. So it appears that pcommit_sfence in that file is wrong then? At least on processors where it falls back on clflush. mwait_idle is th...

...t guaranteed to be ordered by any other fencing or serializing instructions or by another CLFLUSH instruction. For example, software can use an MFENCE instruction to ensure that previous stores are included in the write-back. There are instances of this in mwait_play_dead, clflush_cache_range, mwait_idle_with_hints, mwait_idle .. A comment near pcommit_sfence includes an example flush_and_commit_buffer code which is interesting - it assumes sfence flushes clflush. So it appears that pcommit_sfence in that file is wrong then? At least on processors where it falls back on clflush. mwait_idle is th...

On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > On 01/12/16 14:10, Michael S. Tsirkin wrote: > > mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's > > 2 to 3 times slower than lock; addl $0,(%%e/rsp) that we use on older CPUs. > > > > So let's use the locked variant everywhere - helps keep the code simple as >

On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > On 01/12/16 14:10, Michael S. Tsirkin wrote: > > mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's > > 2 to 3 times slower than lock; addl $0,(%%e/rsp) that we use on older CPUs. > > > > So let's use the locked variant everywhere - helps keep the code simple as >

...>] run_timer_softirq+0x163/0x189 [<f8b8b40a>] htb_rate_timer+0x0/0xc4 [sch_htb] [<c0123315>] __do_softirq+0x70/0xdb [<c01233bb>] do_softirq+0x3b/0x42 [<c0111cda>] smp_apic_timer_interrupt+0x9c/0xb2 [<c0104373>] apic_timer_interrupt+0x1f/0x24 [<c0101cc3>] mwait_idle_with_hints+0x3b/0x3f [<c0101cd3>] mwait_idle+0xc/0x1b [<c010271c>] cpu_idle+0x63/0x79 ======================= BUG: soft lockup detected on CPU#2! [<c013c890>] softlockup_tick+0x93/0xc2 [<c0127585>] update_process_times+0x26/0x5c [<c0111cd5>] smp_apic_timer_interr...

commit f8e617f4582995f7c25ef25b4167213120ad122b ("sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs") adds memory barriers around clflush, but this seems wrong for UP since barrier() has no effect on clflush. We really want mfence so switch to mb() instead. Cc: Mike Galbraith <bitbucket at online.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/...

...s up but kernel panics with the following error: Badness in i8042_panic_blink at drivers/input/serio/i8042.c:992 This is the call trace: apic_timer_interrupt+133 vgacon_cursor+0 oops_end+64 release_console_sem+369 error_exit+0 :scsi_mod:scsi_delete_timer+19 :3w_9xxx:twa_interrupt+1323 do_IRQ+197 mwait_idle+86 cpu_idle+26 The Uni processor works fine. I tried the SMP kernel from Fedora Core 4 x86_64 which works fine as well. Any idea what's going on here? I've already tried disabling as many things from the BIOS as possible. Thanks for any help.

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

...0c>] ? call_softirq+0x1c/0x30 [<ffffffff8100fa75>] ? do_softirq+0x65/0xa0 [<ffffffff8107a6c5>] ? irq_exit+0x85/0x90 [<ffffffff8151b165>] ? do_IRQ+0x75/0xf0 [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 <EOI> [<ffffffff81016627>] ? mwait_idle+0x77/0xd0 [<ffffffff815176fa>] ? atomic_notifier_call_chain+0x1a/0x20 [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 [<ffffffff814f6e3a>] ? rest_init+0x7a/0x80 [<ffffffff81c25f70>] ? start_kernel+0x405/0x411 [<ffffffff81c2533a>] ? x86_64_start_rese...

...000005 (XEN) 0000000000000010 00007fca88236597 000000000000e033 0000000000000202 (XEN) 00007fff297d9368 000000000000e02b (XEN) (XEN) *** Dumping CPU3 host state: *** (XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e008:[<ffff82c4c01a365e>] mwait_idle+0x2bb/0x31c (XEN) RFLAGS: 0000000000000246 CONTEXT: hypervisor (XEN) rax: 0000000000000010 rbx: 000000703cd99b2b rcx: 20c49ba5e353f7cf (XEN) rdx: ffff83043ffc0020 rsi: 000000703cd99b2b rdi: ffff83043ffd0a38 (XEN) rbp: ffff83043c9b7ee0 rsp: ffff83043c9b7e60 r8: 0000000000000000 (XEN)...

...ba3f38] call_softirq at ffffffff8100d15c #28 [ffff880010ba3f50] do_softirq at ffffffff8100e995 #29 [ffff880010ba3f70] irq_exit at ffffffff8105c205 #30 [ffff880010ba3f80] do_IRQ at ffffffff813b2dc5 --- <IRQ stack> --- #31 [ffff88047f0bfe38] ret_from_intr at ffffffff8100c9d3 [exception RIP: mwait_idle+113] RIP: ffffffff810140a1 RSP: ffff88047f0bfee8 RFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88047f0bfef8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88047f0bffd8 RDI: ffffffff8161f308 RBP: ffffffff8100c9ce R8: 0000000000000000 R9: 0000000000000000 R10: 00...

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

...: [361033.894565] [<c0103bc8>] ? do_IRQ+0x2b/0x63 Jun 3 15:03:52 kernel: [361033.894565] [<c0102da9>] ? common_interrupt+0x29/0x30 Jun 3 15:03:52 kernel: [361033.894565] [<c014007b>] ? audit_log_exit+0xb78/0xc8b Jun 3 15:03:52 kernel: [361033.894565] [<c0106f93>] ? mwait_idle+0x75/0xa0 Jun 3 15:03:52 kernel: [361033.894565] [<c0101afc>] ? cpu_idle+0x23/0x3f Jun 3 15:03:52 kernel: [361033.894565] [<c03c88d7>] ? start_kernel+0x262/0x265 Jun 3 15:03:52 kernel: [361033.894565] ---[ end trace 9422ad58c50dc1ad ]--- Jun 3 15:03:54 kernel: [361036.107365]*...

On Wed, Jan 27, 2016 at 04:07:56PM +0200, Michael S. Tsirkin wrote: > mwait_idle is the only one that calls smp_mb and not mb() > I couldn't figure out why - original patches did mb() > there. That probably wants changing. That said, running UP kernels on affected hardware is 'unlikely' :-)

...dcc>] tg3_rx+0x2f1/0x3d8 [<c028ff12>] tg3_poll+0x5f/0x13b [<c02f3124>] net_rx_action+0x6a/0xe5 [<c011a8f2>] __do_softirq+0x7e/0x8a [<c011a924>] do_softirq+0x26/0x28 [<c01048b1>] do_IRQ+0x1e/0x24 [<c0102fb2>] common_interrupt+0x1a/0x20 [<c010116a>] mwait_idle+0x29/0x2e [<c01010d1>] cpu_idle+0x4f/0x58 [<c045070e>] start_kernel+0x14d/0x166 [<c04502f7>] unknown_bootoption+0x0/0x1ab Code: eb e9 80 e2 f8 8b 41 7c 88 51 6d 83 48 10 01 eb 98 55 57 56 53 81 ec c0 00 00 00 8b 94 24 d4 00 00 00 8b 5a 7c 8b 6a 14 8b 72 20 <8b> 43 10 a8...

On 03/23/2011 08:43 AM, Len Brown wrote: > Why is this patch a step forward? Hi Len, I have basically moved the code for arch default and mwait idle from arch/x86/kernel/process.c to a driver. This was suggested by Venki (https://lkml.org/lkml/2010/10/19/460) as part of pm_idle cleanup and direct call of cpuidle_idle_call(). There is not much new code here. > >> +obj-$(CONFIG_X86)

...lt;c04541e6>] handle_IRQ_event+0x1a/0x3f [<c04553f5>] handle_fasteoi_irq+0x64/0x98 [<c0455391>] handle_fasteoi_irq+0x0/0x98 [<c04071f7>] do_IRQ+0xac/0xd1 [<c041ad1f>] smp_apic_timer_interrupt+0x74/0x80 [<c040592b>] common_interrupt+0x23/0x28 [<c0403281>] mwait_idle_with_hints+0x3b/0x3f [<c0403285>] mwait_idle+0x0/0xa [<c04033c9>] cpu_idle+0x96/0xb7 [<c0764a8e>] start_kernel+0x316/0x31e [<c0764227>] unknown_bootoption+0x0/0x202 ======================= Code: 40 54 00 00 00 00 c7 40 58 00 00 00 00 eb 14 89 50 44 c7 40 50 00 00 00 00...