mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	MASAO TAKAHASHI <masao-takahashi@kanno.co.jp>,
	Joerg Roedel <joro@8bytes.org>
Subject: Re: Another preempt folding issue?
Date: Thu, 20 Feb 2014 16:50:41 +0100	[thread overview]
Message-ID: <20140220155041.GG9987@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <53062165.3040202@canonical.com>

On Thu, Feb 20, 2014 at 04:38:13PM +0100, Stefan Bader wrote:
> On 14.02.2014 18:21, Peter Zijlstra wrote:
> > On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
> >> One thing I likely should do is to reinstall the exact same laptop with 64bit
> >> kernel and userspace... maybe only 64bit kernel first... and make sure on my
> >> side that this does not show up on 64bit, too. I took the word of reporters for
> >> that (and the impression that otherwise many more people would have complained).
> > 
> > Yeha, I'm going to try and install some 32bit userspace on a usb
> > harddisk I've got and see if I can boot my Core2 laptop from that to try
> > and reproduce.
> > 
> > But all that is probably going to be Monday :/
> > 
> *sigh* Already Thursday...
> 
> Peter, did you get to reproduce this locally? Unfortunately I had some
> interruption and have not more Information than on last Friday (which is that
> the same hw but 64bit kernel does not show it).

I got side-tracked as well, someone reported crashes, which come above
weird behaviour :/

> Meanwhile I wonder whether it would make sense to push the following (or more?)
> to stable for 3.13.y:
> 
> 1) 16824255394f55adf31b9a96a9965d8c15bdac4c
>    x86, acpi, idle: Restructure the mwait idle routines
> 2) 7e98b71920464b8d15fa95c74366416cd3c88861
>    x86, idle: Use static_cpu_has() for CLFLUSH workaround, add barriers
> 3) 8cb75e0c4ec9786b81439761eac1d18d4a931af3
>    sched/preempt: Fix up missed PREEMPT_NEED_RESCHED folding
> 4) 215393bc1fab3d61a5a296838bdffce22f27ffda
>    sched/preempt/x86: Fix voluntary preempt for x86
> 
> 1+2 would be to avoid touching 3 too much and looked to be improvements on their
> own. 3+4 would be cherry-picks if not for some fuzz 2.

I'll not object; but if someone wants a smaller set you could do with
just the idle.c hunk from 3.

> I saw a few more things labelled preempt between 3.13 and current HEAD but am
> not sure whether or which of those are strictly required. Namely some fixing to
> preempt_enable_no_resched() mis-usage and maybe one fixing an issue of ftrace
> locking up.

Yeah, that's all fresh breakage and doesn't go back to 3.13 I think.

  reply	other threads:[~2014-02-20 15:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 18:34 Stefan Bader
2014-02-11 19:45 ` Peter Zijlstra
2014-02-12  8:20   ` Stefan Bader
2014-02-12 10:37     ` Peter Zijlstra
2014-02-12 10:40       ` Borislav Petkov
2014-02-12 11:09         ` Stefan Bader
2014-02-12 11:54           ` Peter Zijlstra
2014-02-13 17:00             ` Stefan Bader
2014-02-13 17:38               ` Peter Zijlstra
2014-02-13 18:03                 ` Stefan Bader
2014-02-13 18:26                   ` Peter Zijlstra
2014-02-14 13:34                     ` Borislav Petkov
2014-02-14 13:40                       ` Stefan Bader
2014-02-14 14:24                       ` Stefan Bader
2014-02-14 14:47                         ` Borislav Petkov
2014-02-14 17:02                           ` Stefan Bader
2014-02-14 17:21                             ` Peter Zijlstra
2014-02-20 15:38                               ` Stefan Bader
2014-02-20 15:50                                 ` Peter Zijlstra [this message]
2014-03-24 17:39                                   ` Paolo Bonzini
2014-03-25  8:23                                     ` Stefan Bader
2014-02-14 17:33                             ` Borislav Petkov
2014-02-14 18:23                               ` Stefan Bader
2014-02-14 19:03                                 ` Stefan Bader
2014-02-14 15:21                         ` Another preempt folding issue? (maybe bisect) Borislav Petkov
2014-02-14 15:28                           ` Stefan Bader
2014-02-14 15:44                             ` Borislav Petkov
2014-02-14 16:21                           ` Peter Zijlstra
2014-02-13 18:25               ` Another preempt folding issue? Peter Zijlstra
2014-02-14 10:55                 ` Stefan Bader
2014-02-14 13:17                   ` Peter Zijlstra
2014-02-14 11:24                 ` Stefan Bader
2014-02-14 11:49                   ` Peter Zijlstra
2014-02-12 11:12         ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140220155041.GG9987@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@alien8.de \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masao-takahashi@kanno.co.jp \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stefan.bader@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome