Hello, Joe.
On Sun, Sep 28, 2014 at 12:39:34PM -0400, Joe Lawrence wrote:
> On Sun, 28 Sep 2014, Tejun Heo wrote:
> > Hello, Joe.
> >
> > On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
> > ...
> > > I was wondering if such behavior was expected on !PREEMPT kernels,
> > >
On Sun, 28 Sep 2014, Tejun Heo wrote:
> Hello, Joe.
>
> On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
> ...
> > I was wondering if such behavior was expected on !PREEMPT kernels,
> > especially after b22ce2785d97 "workqueue: cond_resched() after
> > processing each work item".
Hello, Joe.
On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
...
> I was wondering if such behavior was expected on !PREEMPT kernels,
> especially after b22ce2785d97 "workqueue: cond_resched() after
> processing each work item". In the ftraces I've observed from the RCU
> stall,
Hello, Joe.
On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
...
I was wondering if such behavior was expected on !PREEMPT kernels,
especially after b22ce2785d97 workqueue: cond_resched() after
processing each work item. In the ftraces I've observed from the RCU
stall,
On Sun, 28 Sep 2014, Tejun Heo wrote:
Hello, Joe.
On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
...
I was wondering if such behavior was expected on !PREEMPT kernels,
especially after b22ce2785d97 workqueue: cond_resched() after
processing each work item. In the
Hello, Joe.
On Sun, Sep 28, 2014 at 12:39:34PM -0400, Joe Lawrence wrote:
On Sun, 28 Sep 2014, Tejun Heo wrote:
Hello, Joe.
On Fri, Sep 26, 2014 at 10:52:27AM -0400, Joe Lawrence wrote:
...
I was wondering if such behavior was expected on !PREEMPT kernels,
especially after
Hello Tejun,
(RHEL7 kernel, see config below)
I'm debugging an RCU stall where it seems that the culprit is a kworker
workqueue function that decides to reschedule itself over and over via
schedule_delayed_work with a 0 jiffy delay. If I watch rcudata, I can
see that the CPU currently running
Hello Tejun,
(RHEL7 kernel, see config below)
I'm debugging an RCU stall where it seems that the culprit is a kworker
workqueue function that decides to reschedule itself over and over via
schedule_delayed_work with a 0 jiffy delay. If I watch rcudata, I can
see that the CPU currently running
8 matches
Mail list logo