On Wed, Apr 01, 2015 at 09:56:07AM +0200, Peter Zijlstra wrote:
> > The problem with this is that workqueue currently doesn't distinguish
> > why work items are queued on per-cpu workqueues. It can't tell
> > whether being bound to local CPU is for correctness or optimization
> > and thus can't
On Tue, Mar 31, 2015 at 03:37:45PM -0400, Tejun Heo wrote:
> Hello, Chris.
>
> On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
> > From: Chris Metcalf
> >
> > When queuing work, we should avoid queuing it on the local cpu if
> > we are using WORK_CPU_UNBOUND and the local
On Tue, Mar 31, 2015 at 03:37:45PM -0400, Tejun Heo wrote:
Hello, Chris.
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf cmetc...@ezchip.com
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the
On Wed, Apr 01, 2015 at 09:56:07AM +0200, Peter Zijlstra wrote:
The problem with this is that workqueue currently doesn't distinguish
why work items are queued on per-cpu workqueues. It can't tell
whether being bound to local CPU is for correctness or optimization
and thus can't break
On Tue, Mar 31, 2015 at 10:58:41PM +0200, Frederic Weisbecker wrote:
> On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
> > From: Chris Metcalf
> >
> > When queuing work, we should avoid queuing it on the local cpu if
> > we are using WORK_CPU_UNBOUND and the local cpu is
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
> From: Chris Metcalf
>
> When queuing work, we should avoid queuing it on the local cpu if
> we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
> the workqueue will mean a later interrupt of the nohz_full
Hello, Chris.
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
> From: Chris Metcalf
>
> When queuing work, we should avoid queuing it on the local cpu if
> we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
> the workqueue will mean a later interrupt of the
From: Chris Metcalf
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
the workqueue will mean a later interrupt of the nohz_full process
that presumably would prefer continuing to have 100% of the core
without
Hello, Chris.
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf cmetc...@ezchip.com
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
the workqueue will mean a later
From: Chris Metcalf cmetc...@ezchip.com
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
the workqueue will mean a later interrupt of the nohz_full process
that presumably would prefer continuing to have 100% of
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf cmetc...@ezchip.com
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the local cpu is nohz_full, since
the workqueue will mean a later interrupt of the
On Tue, Mar 31, 2015 at 10:58:41PM +0200, Frederic Weisbecker wrote:
On Tue, Mar 31, 2015 at 03:25:59PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf cmetc...@ezchip.com
When queuing work, we should avoid queuing it on the local cpu if
we are using WORK_CPU_UNBOUND and the local
12 matches
Mail list logo