On Tue, Oct 25, 2016 at 09:55:21AM -0700, Eric Wheeler wrote:
> Sure, I'll put it up with my -rc2 pull request to Jens.
>
> A couple of sanity checks (for my understanding at least):
>
> Why does bch_data_insert_start() no longer need to call
> set_gc_sectors(op->c) now that bch_cache_set_allo
On Mon, 24 Oct 2016, Kent Overstreet wrote:
> On Sun, Oct 23, 2016 at 06:57:26PM -0700, Davidlohr Bueso wrote:
> > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> >
> > > Subject: sched: Better explain sleep/wakeup
> > > From: Peter Zijlstra
> > > Date: Wed Oct 19 15:45:27 CEST 2016
> > >
> > > The
On Sun, Oct 23, 2016 at 06:57:26PM -0700, Davidlohr Bueso wrote:
> On Wed, 19 Oct 2016, Peter Zijlstra wrote:
>
> > Subject: sched: Better explain sleep/wakeup
> > From: Peter Zijlstra
> > Date: Wed Oct 19 15:45:27 CEST 2016
> >
> > There were a few questions wrt how sleep-wakeup works. Try and
On Sun, Oct 23, 2016 at 06:57:26PM -0700, Davidlohr Bueso wrote:
> On Wed, 19 Oct 2016, Peter Zijlstra wrote:
>
> > Subject: sched: Better explain sleep/wakeup
> > From: Peter Zijlstra
> > Date: Wed Oct 19 15:45:27 CEST 2016
> >
> > There were a few questions wrt how sleep-wakeup works. Try and
On Wed, 19 Oct 2016, Peter Zijlstra wrote:
Subject: sched: Better explain sleep/wakeup
From: Peter Zijlstra
Date: Wed Oct 19 15:45:27 CEST 2016
There were a few questions wrt how sleep-wakeup works. Try and explain
it more.
Requested-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> > if (!first && __mutex_waiter_is_first(lock, &waiter)) {
> > first = true;
> > __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> > }
> > +
> > + set_task_state(task,
On Mon, Oct 17, 2016 at 07:16:50PM -0400, Waiman Long wrote:
> >+++ b/kernel/locking/mutex.c
> >@@ -631,13 +631,21 @@ __mutex_lock_common(struct mutex *lock,
> >
> > lock_contended(&lock->dep_map, ip);
> >
> >+set_task_state(task, state);
>
> Do we want to set the state here? I am not sure
On 10/07/2016 10:52 AM, Peter Zijlstra wrote:
Doesn't really matter yet, but pull the HANDOFF and trylock out from
under the wait_lock.
The intention is to add an optimistic spin loop here, which requires
we do not hold the wait_lock, so shuffle code around in preparation.
Also clarify the purp
On Mon, Oct 17, 2016 at 09:45:01PM +0800, Boqun Feng wrote:
> But __mutex_set_flag() and __mutex_trylock() actually touch the same
> atomic word? So we don't need extra things to order them?
Right.. in any case brain is confused. I'll look again at it later.
On Mon, Oct 17, 2016 at 03:24:08PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 12:44:49PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> > > Hi Peter,
> > >
> > > I'm struggling to get my head around the handoff code after this change...
On Mon, Oct 17, 2016 at 12:44:49PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> > Hi Peter,
> >
> > I'm struggling to get my head around the handoff code after this change...
> >
> > On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
>
On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> Hi Peter,
>
> I'm struggling to get my head around the handoff code after this change...
>
> On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -631
Hi Peter,
I'm struggling to get my head around the handoff code after this change...
On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -631,13 +631,21 @@ __mutex_lock_common(struct mutex *lock,
>
> lock_conte
13 matches
Mail list logo
