Adding a few more Cc's for bcache.
On Tue, 22 Mar 2016, Peter Zijlstra wrote:
On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
+/*
+ * Helpers for modifying the state of either the current task, or a foreign
+ * task. Each of these calls come in both full barrier and weak
Adding a few more Cc's for bcache.
On Tue, 22 Mar 2016, Peter Zijlstra wrote:
On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
+/*
+ * Helpers for modifying the state of either the current task, or a foreign
+ * task. Each of these calls come in both full barrier and weak
On Tue, Mar 22, 2016 at 05:41:22PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 03:45:37PM +0100, Heiko Carstens wrote:
>
> > Sure, looks nice and makes a lot of sense. And the text looks a bit familiar
> > to me ;)
> >
> > Could you provide From: and Signed-off-by: lines?
>
> Of
On Tue, Mar 22, 2016 at 05:41:22PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 03:45:37PM +0100, Heiko Carstens wrote:
>
> > Sure, looks nice and makes a lot of sense. And the text looks a bit familiar
> > to me ;)
> >
> > Could you provide From: and Signed-off-by: lines?
>
> Of
On Tue, Mar 22, 2016 at 03:45:37PM +0100, Heiko Carstens wrote:
> Sure, looks nice and makes a lot of sense. And the text looks a bit familiar
> to me ;)
>
> Could you provide From: and Signed-off-by: lines?
Of course, find below.
---
Subject: s390: Clarify pagefault interrupt
From: Peter
On Tue, Mar 22, 2016 at 03:45:37PM +0100, Heiko Carstens wrote:
> Sure, looks nice and makes a lot of sense. And the text looks a bit familiar
> to me ;)
>
> Could you provide From: and Signed-off-by: lines?
Of course, find below.
---
Subject: s390: Clarify pagefault interrupt
From: Peter
On Tue, Mar 22, 2016 at 02:55:30PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 02:26:00PM +0100, Heiko Carstens wrote:
> > > Clearly something magical is going on and its not clear.
> >
> > The mechanism of our pfault code: if Linux is running as guest, runs a user
> > space process
On Tue, Mar 22, 2016 at 02:55:30PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 02:26:00PM +0100, Heiko Carstens wrote:
> > > Clearly something magical is going on and its not clear.
> >
> > The mechanism of our pfault code: if Linux is running as guest, runs a user
> > space process
On Tue, Mar 22, 2016 at 02:26:00PM +0100, Heiko Carstens wrote:
> > Clearly something magical is going on and its not clear.
>
> The mechanism of our pfault code: if Linux is running as guest, runs a user
> space process and the user space process accesses a page that the host has
> paged out we
On Tue, Mar 22, 2016 at 02:26:00PM +0100, Heiko Carstens wrote:
> > Clearly something magical is going on and its not clear.
>
> The mechanism of our pfault code: if Linux is running as guest, runs a user
> space process and the user space process accesses a page that the host has
> paged out we
On Tue, Mar 22, 2016 at 01:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> > On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
>
> > > And s390 does something entirely vile, no idea what.
> >
> > For the two s390 usages tsk
On Tue, Mar 22, 2016 at 01:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> > On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
>
> > > And s390 does something entirely vile, no idea what.
> >
> > For the two s390 usages tsk
On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> > And s390 does something entirely vile, no idea what.
>
> For the two s390 usages tsk equals current. So it could be easily replaced
> with set_current_state().
On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> > And s390 does something entirely vile, no idea what.
>
> For the two s390 usages tsk equals current. So it could be easily replaced
> with set_current_state().
On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
>
> > +/*
> > + * Helpers for modifying the state of either the current task, or a foreign
> > + * task. Each of these calls come in both full barrier and weak
On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
>
> > +/*
> > + * Helpers for modifying the state of either the current task, or a foreign
> > + * task. Each of these calls come in both full barrier and weak
On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
> +/*
> + * Helpers for modifying the state of either the current task, or a foreign
> + * task. Each of these calls come in both full barrier and weak flavors:
> + *
> + * Weak
> + *
On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
> +/*
> + * Helpers for modifying the state of either the current task, or a foreign
> + * task. Each of these calls come in both full barrier and weak flavors:
> + *
> + * Weak
> + *
On Mon, 14 Mar 2016, Peter Zijlstra wrote:
So you're right that it doesn't matter here, however for that very
reason I would suggest not using __set_current_state() before schedule()
unless there is a _really_ good reason, and then with an extensive
comment to go with.
No problem.
On Mon, 14 Mar 2016, Peter Zijlstra wrote:
So you're right that it doesn't matter here, however for that very
reason I would suggest not using __set_current_state() before schedule()
unless there is a _really_ good reason, and then with an extensive
comment to go with.
No problem.
On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote:
> The very nature of rt_mutex_handle_deadlock() implies that this
> patch is merely a formality, as in practice the saved barrier
> is of little use. That said, we can relax setting the task state
> and be done with it; blocking
On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote:
> The very nature of rt_mutex_handle_deadlock() implies that this
> patch is merely a formality, as in practice the saved barrier
> is of little use. That said, we can relax setting the task state
> and be done with it; blocking
The very nature of rt_mutex_handle_deadlock() implies that this
patch is merely a formality, as in practice the saved barrier
is of little use. That said, we can relax setting the task state
and be done with it; blocking unconditionally... this is a deadlock!
Signed-off-by: Davidlohr Bueso
The very nature of rt_mutex_handle_deadlock() implies that this
patch is merely a formality, as in practice the saved barrier
is of little use. That said, we can relax setting the task state
and be done with it; blocking unconditionally... this is a deadlock!
Signed-off-by: Davidlohr Bueso
---
24 matches
Mail list logo
