On 04/19/2016 10:55 AM, Mike Galbraith wrote:
> I can't get to my DL980 to do jitter testing atm (network outage), but
> wrt hotplug banging, my local boxen say patch is toxic. i4790 desktop
> box silently bricked once too. The boom begins with...
>
>BUG: scheduling while atomic: futex_wait/
On Tue, 2016-04-19 at 09:07 +0200, Sebastian Andrzej Siewior wrote:
> On 04/18/2016 07:55 PM, Mike Galbraith wrote:
> >
> > I'll have to feed it to DL980, hotplug and jitter test it. It seemed
> > to think that pinning post acquisition was a bad idea jitter wise, but
> > I was bending things up w
On 04/18/2016 07:55 PM, Mike Galbraith wrote:
>
> I'll have to feed it to DL980, hotplug and jitter test it. It seemed
> to think that pinning post acquisition was a bad idea jitter wise, but
> I was bending things up while juggling multiple boxen, so..
pinning pre acquisition could get you in a
On Mon, 2016-04-18 at 19:15 +0200, Sebastian Andrzej Siewior wrote:
> take 2. There is this else case in pin_current_cpu() where I take
> hp_lock. I didn't manage to get in there. So I *think* we can get rid of
> the lock now. Since there is no lock (or will be) we can drop the whole
> `do_mig_dis
* Mike Galbraith | 2016-04-08 18:49:28 [+0200]:
>On Fri, 2016-04-08 at 16:51 +0200, Sebastian Andrzej Siewior wrote:
>
>> Is there anything you can hand me over?
>
>Sure, I'll send it offline (yup, that proud of my scripting;)
>
> -Mike
take 2. There is this else case in pin_current_cpu() w
On Fri, 2016-04-08 at 16:51 +0200, Sebastian Andrzej Siewior wrote:
> Is there anything you can hand me over?
Sure, I'll send it offline (yup, that proud of my scripting;)
-Mike
On 04/08/2016 04:16 PM, Mike Galbraith wrote:
>> okay. and how did you trigger this? Just Steven's script or was there
>> more to it?
>
> I run stockfish, futextest, hackbench and tbench with it, terminating
> and restarting them at random intervals just to make sure nobody gets
> into a comfortab
On Fri, 2016-04-08 at 15:58 +0200, Sebastian Andrzej Siewior wrote:
> On 04/08/2016 03:44 PM, Mike Galbraith wrote:
> > On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
> >
> > > just to be clear: The patch I attached did _not_ work for you.
> >
> > Did you perchance mean with
On 04/08/2016 03:44 PM, Mike Galbraith wrote:
> On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
>
>> just to be clear: The patch I attached did _not_ work for you.
>
> Did you perchance mean with "Reenable migration across schedule"
> reverted? Figured it would still explode
On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
> just to be clear: The patch I attached did _not_ work for you.
Did you perchance mean with "Reenable migration across schedule"
reverted? Figured it would still explode in seconds.. it did.
[ 172.996232] kernel BUG at kernel
On Fri, 2016-04-08 at 12:30 +0200, Sebastian Andrzej Siewior wrote:
> On 04/07/2016 09:04 PM, Mike Galbraith wrote:
> > > just to be clear: The patch I attached did _not_ work for you.
> >
> > Sorry, I didn't test. Marathon stress test session convinced me that
> > the lock added by -rt absolutel
On 04/07/2016 09:04 PM, Mike Galbraith wrote:
>> just to be clear: The patch I attached did _not_ work for you.
>
> Sorry, I didn't test. Marathon stress test session convinced me that
> the lock added by -rt absolutely had to die.
Okay. And the patch did that. I removed the lock.
>>> If that l
On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
> > If that lock dies, we can unpin when entering lock slow path and pin
> > again post acquisition with no ABBA worries as well, and not only does
> > existing hotplug work heaping truckloads better, -rt can perhaps help
> > spot
On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
> On 04/02/2016 05:12 AM, Mike Galbraith wrote:
> > > By the time I improved hotplug I played with this. I had a few ideas but
> > > it didn't fly in the end. Today however I ended up with this:
> >
> > Yeah, but that fails the du
On 04/02/2016 05:12 AM, Mike Galbraith wrote:
>> By the time I improved hotplug I played with this. I had a few ideas but
>> it didn't fly in the end. Today however I ended up with this:
>
> Yeah, but that fails the duct tape test too. Mine is below, and is the
> extra sticky variety ;-) With bu
On Fri, 2016-04-01 at 23:11 +0200, Sebastian Andrzej Siewior wrote:
> * Mike Galbraith | 2016-03-31 08:31:43 [+0200]:
>
> > 3. nuke irksome grab_lock: make everybody always try to get the hell
> > outta Dodge or hotplug can bloody well wait.
> >
> > I haven't yet flogged my 64 core box doing that
* Mike Galbraith | 2016-03-31 08:31:43 [+0200]:
>3. nuke irksome grab_lock: make everybody always try to get the hell
>outta Dodge or hotplug can bloody well wait.
>
>I haven't yet flogged my 64 core box doing that, but my local boxen
>seem to be saying we don't really really need the grab_lock bu
On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> I really wonder what makes the change. The only thing which comes to my mind
> is the enforcement of running the online and down_prepare callbacks on the
> plugged cpu instead of doing it wherever the scheduler decides to run it.
It seem
On Fri, 2016-03-25 at 17:24 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-25 at 10:13 +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-25 at 09:52 +0100, Thomas Gleixner wrote:
> > > On Fri, 25 Mar 2016, Mike Galbraith wrote:
> > > > On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > > >
On Fri, 2016-03-25 at 10:13 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-25 at 09:52 +0100, Thomas Gleixner wrote:
> > On Fri, 25 Mar 2016, Mike Galbraith wrote:
> > > On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > > > On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> > >
Rock #1..
hotplug/rt: Nest module_mutex inside cpu_hotplug.lock
PID: 11107 TASK: 8803b12b9900 CPU: 4 COMMAND: "stress-cpu-hotp"
On Fri, 2016-03-25 at 09:52 +0100, Thomas Gleixner wrote:
> On Fri, 25 Mar 2016, Mike Galbraith wrote:
> > On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > > On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> > > >
> > > > > On the bright side, with the busted migrate enable
On Fri, 25 Mar 2016, Mike Galbraith wrote:
> On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> > On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> > >
> > > > On the bright side, with the busted migrate enable business reverted,
> > > > plus one dinky change from me [1], master
On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> >
> > > On the bright side, with the busted migrate enable business reverted,
> > > plus one dinky change from me [1], master-rt.today has completed 100
> > > iterations of Steve
On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
>
> > On the bright side, with the busted migrate enable business reverted,
> > plus one dinky change from me [1], master-rt.today has completed 100
> > iterations of Steven's hotplug stress script along side endless
> > futexstress, and i
On Thu, 24 Mar 2016, Mike Galbraith wrote:
> On Sun, 2016-03-20 at 09:43 +0100, Mike Galbraith wrote:
> > On Sat, 2016-02-13 at 00:02 +0100, Sebastian Andrzej Siewior wrote:
> > > From: Thomas Gleixner
> > >
> > > We currently disable migration across lock acquisition. That includes the
> > > pa
On Sun, 2016-03-20 at 09:43 +0100, Mike Galbraith wrote:
> On Sat, 2016-02-13 at 00:02 +0100, Sebastian Andrzej Siewior wrote:
> > From: Thomas Gleixner
> >
> > We currently disable migration across lock acquisition. That includes the
> > part
> > where we block on the lock and schedule out. We
On Sat, 2016-02-13 at 00:02 +0100, Sebastian Andrzej Siewior wrote:
> From: Thomas Gleixner
>
> We currently disable migration across lock acquisition. That includes the part
> where we block on the lock and schedule out. We cannot disable migration after
> taking the lock as that would cause a p
From: Thomas Gleixner
We currently disable migration across lock acquisition. That includes the part
where we block on the lock and schedule out. We cannot disable migration after
taking the lock as that would cause a possible lock inversion.
But we can be smart and enable migration when we bloc
29 matches
Mail list logo
