Hi Prasad,
On Wed, Aug 01, 2018 at 01:07:03AM -0700, Sodagudi Prasad wrote:
> On 2018-07-30 14:07, Peter Zijlstra wrote:
> >On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote:
> >>How about including below change as well? Currently, there is
> >>no way to
> >>identify thread migratio
On 2018-07-30 14:07, Peter Zijlstra wrote:
On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote:
How about including below change as well? Currently, there is no way
to
identify thread migrations completed or not. When we observe this
issue,
the symptom was work queue lock up. It i
On Mon, Jul 30, 2018 at 10:12:43AM -0700, Sodagudi Prasad wrote:
> How about including below change as well? Currently, there is no way to
> identify thread migrations completed or not. When we observe this issue,
> the symptom was work queue lock up. It is better to have some timeout here
> and
On Mon, 30 Jul 2018, Sodagudi Prasad wrote:
> How about including below change as well? Currently, there is no way to
That would be a completely separate change.
> identify thread migrations completed or not. When we observe this issue, the
> symptom was work queue lock up. It is better to have
On 2018-07-30 05:41, Thomas Gleixner wrote:
On Mon, 30 Jul 2018, Peter Zijlstra wrote:
On Mon, Jul 30, 2018 at 12:20:57PM +0200, Thomas Gleixner wrote:
> On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote:
> > On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> > > Hi all,
> > Hi,
On Mon, 30 Jul 2018, Peter Zijlstra wrote:
> On Mon, Jul 30, 2018 at 12:20:57PM +0200, Thomas Gleixner wrote:
> > On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote:
> > > On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> > > > Hi all,
> > > Hi,
> > >
> > > > Are there any comments
On Mon, Jul 30, 2018 at 12:20:57PM +0200, Thomas Gleixner wrote:
> On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote:
> > On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> > > Hi all,
> > Hi,
> >
> > > Are there any comments about this patch?
> >
> > I haven't look in detail at th
On Tue, 24 Jul 2018, Sebastian Andrzej Siewior wrote:
> On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> > Hi all,
> Hi,
>
> > Are there any comments about this patch?
>
> I haven't look in detail at this but your new preempt_disable() makes
> things unbalanced for the err != 0 case
Hi Sebastian,
Thanks for the response.
"I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case."
This cannot happen. The only possible return values of this function
are -ENOENT or 0.
In the case where we return -ENOENT, we'll go
straight
On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> Hi all,
Hi,
> Are there any comments about this patch?
I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case.
> Thanks,
> Isaac Manjarres
Sebastian
Hi all,
Are there any comments about this patch?
Thanks,
Isaac Manjarres
On 2018-07-17 12:35, Isaac J. Manjarres wrote:
This commit:
9fb8d5dc4b64 ("stop_machine, Disable preemption when
waking two stopper threads")
does not fully address the race condition that can occur
as follows:
On one C
This commit:
9fb8d5dc4b64 ("stop_machine, Disable preemption when
waking two stopper threads")
does not fully address the race condition that can occur
as follows:
On one CPU, call it CPU 3, thread 1 invokes
cpu_stop_queue_two_works(2, 3,...), and the execution is such
that thread 1 queues the w
12 matches
Mail list logo
