On Mon, Oct 12, 2015 at 09:09:24PM +0800, Boqun Feng wrote:
> On Mon, Oct 12, 2015 at 01:54:38PM +0200, Peter Zijlstra wrote:
> > On Mon, Oct 12, 2015 at 05:06:36PM +0800, Boqun Feng wrote:
> > > Understood.
> > >
> > > But, IMO, the position of this section is already misleading:
> > >
> > > (*)
On Mon, Oct 12, 2015 at 01:54:38PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 05:06:36PM +0800, Boqun Feng wrote:
> > Understood.
> >
> > But, IMO, the position of this section is already misleading:
> >
> > (*) Implicit kernel memory barriers.
> > - Locking functions.
> > -
On Mon, Oct 12, 2015 at 05:06:36PM +0800, Boqun Feng wrote:
> Understood.
>
> But, IMO, the position of this section is already misleading:
>
> (*) Implicit kernel memory barriers.
> - Locking functions.
> - Interrupt disabling functions.
>->- Sleep and wake-up functions.<-
> -
On Sun, Oct 11, 2015 at 05:40:44PM -0700, Paul E. McKenney wrote:
> On Sun, Oct 11, 2015 at 11:26:40PM +0800, Boqun Feng wrote:
> > On Tue, Oct 06, 2015 at 06:06:50PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > > > > Included in it are some of
On Sun, Oct 11, 2015 at 11:26:40PM +0800, Boqun Feng wrote:
> On Tue, Oct 06, 2015 at 06:06:50PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > > > Included in it are some of the details on this subject, because a wakeup
> > > > has two prior states
On Tue, Oct 06, 2015 at 06:06:50PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > > Included in it are some of the details on this subject, because a wakeup
> > > has two prior states that are of importance, the tasks own prior state
> > > and the wak
On Wed, Oct 07, 2015 at 01:10:24PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2015 at 06:04:50PM +0200, Peter Zijlstra wrote:
> > That said, it would be good if Paul (or anyone really) can explain to me
> > the reason for: 5af4692a75da ("smp: Make control dependencies work on
> > Alpha, improve
On Tue, Oct 06, 2015 at 06:04:50PM +0200, Peter Zijlstra wrote:
> That said, it would be good if Paul (or anyone really) can explain to me
> the reason for: 5af4692a75da ("smp: Make control dependencies work on
> Alpha, improve documentation"). The Changelog simply states that Alpha
> needs the mb,
> On Mon, Sep 21, 2015 at 07:46:11PM +0200, Oleg Nesterov wrote:
> > In short, I got lost ;) Now I don't even understand why we do not need
> > another rmb() between p->on_rq and p->on_cpu. Suppose a thread T does
> >
> > set_current_state(...);
> > schedule();
> >
> > it can be preempte
On Tue, Oct 06, 2015 at 06:24:23PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2015 at 06:04:50PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 21, 2015 at 07:46:11PM +0200, Oleg Nesterov wrote:
> > > On 09/18, Peter Zijlstra wrote:
> > > >
> > > > the text is correct, right?
> > >
> > > Yes, it
On Tue, Oct 06, 2015 at 06:04:50PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 21, 2015 at 07:46:11PM +0200, Oleg Nesterov wrote:
> > On 09/18, Peter Zijlstra wrote:
> > >
> > > the text is correct, right?
> >
> > Yes, it looks good to me and helpful.
> >
> > But damn. I forgot why exactly try_to_
On Thu, Sep 24, 2015 at 09:21:22PM +0800, Boqun Feng wrote:
> > Included in it are some of the details on this subject, because a wakeup
> > has two prior states that are of importance, the tasks own prior state
> > and the wakeup state, both should be considered in the 'program order'
> > flow.
>
On Mon, Sep 21, 2015 at 07:46:11PM +0200, Oleg Nesterov wrote:
> On 09/18, Peter Zijlstra wrote:
> >
> > the text is correct, right?
>
> Yes, it looks good to me and helpful.
>
> But damn. I forgot why exactly try_to_wake_up() needs rmb() after
> ->on_cpu check... It looks reasonable in any case,
Hi Peter,
On Thu, Sep 17, 2015 at 03:01:26PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 10, 2015 at 07:55:57PM +0200, Oleg Nesterov wrote:
> > On 09/10, Boqun Feng wrote:
> > >
> > > On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote:
> > > > My feeling is
> > > > that we should avoi
On 09/18, Peter Zijlstra wrote:
>
> the text is correct, right?
Yes, it looks good to me and helpful.
But damn. I forgot why exactly try_to_wake_up() needs rmb() after
->on_cpu check... It looks reasonable in any case, but I do not
see any strong reason immediately.
Say,
p->sched_contri
On Thu, Sep 17, 2015 at 07:01:11PM +0200, Oleg Nesterov wrote:
> On 09/17, Peter Zijlstra wrote:
> >
> > Included in it are some of the details on this subject, because a wakeup
> > has two prior states that are of importance, the tasks own prior state
> > and the wakeup state, both should be consi
On 09/17, Peter Zijlstra wrote:
>
> Included in it are some of the details on this subject, because a wakeup
> has two prior states that are of importance, the tasks own prior state
> and the wakeup state, both should be considered in the 'program order'
> flow.
Great. Just one question,
> + *
On Thu, Sep 10, 2015 at 07:55:57PM +0200, Oleg Nesterov wrote:
> On 09/10, Boqun Feng wrote:
> >
> > On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote:
> > > My feeling is
> > > that we should avoid saying too much about the internals of wait_event()
> > > and wake_up().
>
> I feel
Hi Oleg,
On Thu, Sep 10, 2015 at 07:55:57PM +0200, Oleg Nesterov wrote:
> On 09/10, Boqun Feng wrote:
> >
> > On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote:
> > > My feeling is
> > > that we should avoid saying too much about the internals of wait_event()
> > > and wake_up().
>
On 09/10, Boqun Feng wrote:
>
> On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote:
> > My feeling is
> > that we should avoid saying too much about the internals of wait_event()
> > and wake_up().
I feel the same. I simply can't understand what we are trying to
document ;)
For exam
On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote:
> On Tue, Sep 08, 2015 at 09:14:01AM +0800, Boqun Feng wrote:
> > Two examples for barriers in wake_up() and co. in memory-barriers.txt
> > are misleading, along with their explanations:
> >
> > 1. The example which wanted to expla
On Tue, Sep 08, 2015 at 09:14:01AM +0800, Boqun Feng wrote:
> Two examples for barriers in wake_up() and co. in memory-barriers.txt
> are misleading, along with their explanations:
>
> 1.The example which wanted to explain the write barrier in
> wake_up() and co. [spotted by Oleg Nestero
Two examples for barriers in wake_up() and co. in memory-barriers.txt
are misleading, along with their explanations:
1. The example which wanted to explain the write barrier in
wake_up() and co. [spotted by Oleg Nesterov ]
2. The example which wanted to explain that the write ba
23 matches
Mail list logo