On Tue, 31 Mar 2015 20:18:36 -0300
Marcelo Tosatti wrote:
> On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
> > On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> > > CPUs with nohz_full do not want disruption from timer interrupts,
> > > or other random system
On Tue, 31 Mar 2015 20:18:36 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other
On Tue, 2015-03-31 at 10:27 -0400, Rik van Riel wrote:
> CPUs with nohz_full do not want disruption from timer interrupts,
> or other random system things. This includes block mq work.
>
> There is another issue with block mq vs. realtime tasks that run
> 100% of the time, which is not uncommon
On Tue, 2015-03-31 at 10:27 -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not uncommon on
On 04/01/2015 10:12 AM, Rik van Riel wrote:
On 03/31/2015 11:43 AM, Jens Axboe wrote:
That'd be easy enough to do, that's how blk-mq handles offline CPUs as
well. The attached patch is completely untested, but will handle offline
or nohz CPUs in the same fashion - they will punt to hardware
On 04/01/2015 10:12 AM, Rik van Riel wrote:
On 03/31/2015 11:43 AM, Jens Axboe wrote:
That'd be easy enough to do, that's how blk-mq handles offline CPUs as
well. The attached patch is completely untested, but will handle offline
or nohz CPUs in the same fashion - they will punt to hardware
On 03/31/2015 11:43 AM, Jens Axboe wrote:
> That'd be easy enough to do, that's how blk-mq handles offline CPUs as
> well. The attached patch is completely untested, but will handle offline
> or nohz CPUs in the same fashion - they will punt to hardware queue 0,
> which is mapped to CPU0 (and
On 04/01/2015 08:45 AM, Rik van Riel wrote:
On 04/01/2015 10:36 AM, Jens Axboe wrote:
That wont work for blk-mq, we rely on the characteristics of bound
workqueues. So it would have to be handled up front, like in the patch I
sent out.
Your patch from yesterday looks good. I'll take it for
On 04/01/2015 10:36 AM, Jens Axboe wrote:
That wont work for blk-mq, we rely on the characteristics of bound
workqueues. So it would have to be handled up front, like in the patch I
sent out.
Your patch from yesterday looks good. I'll take it for
a spin today (had some other stuff on my
On 03/31/2015 05:17 PM, Marcelo Tosatti wrote:
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks
On 03/31/2015 05:17 PM, Marcelo Tosatti wrote:
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks
On 04/01/2015 10:36 AM, Jens Axboe wrote:
That wont work for blk-mq, we rely on the characteristics of bound
workqueues. So it would have to be handled up front, like in the patch I
sent out.
Your patch from yesterday looks good. I'll take it for
a spin today (had some other stuff on my
On 04/01/2015 08:45 AM, Rik van Riel wrote:
On 04/01/2015 10:36 AM, Jens Axboe wrote:
That wont work for blk-mq, we rely on the characteristics of bound
workqueues. So it would have to be handled up front, like in the patch I
sent out.
Your patch from yesterday looks good. I'll take it for
On 03/31/2015 11:43 AM, Jens Axboe wrote:
That'd be easy enough to do, that's how blk-mq handles offline CPUs as
well. The attached patch is completely untested, but will handle offline
or nohz CPUs in the same fashion - they will punt to hardware queue 0,
which is mapped to CPU0 (and others,
On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
> On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> > CPUs with nohz_full do not want disruption from timer interrupts,
> > or other random system things. This includes block mq work.
> >
> > There is another
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> CPUs with nohz_full do not want disruption from timer interrupts,
> or other random system things. This includes block mq work.
>
> There is another issue with block mq vs. realtime tasks that run
> 100% of the time, which is not
On 03/31/2015 09:33 AM, Frederic Weisbecker wrote:
On Tue, Mar 31, 2015 at 09:07:11AM -0600, Jens Axboe wrote:
On 03/31/2015 08:27 AM, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is
On Tue, Mar 31, 2015 at 09:07:11AM -0600, Jens Axboe wrote:
> On 03/31/2015 08:27 AM, Rik van Riel wrote:
> >CPUs with nohz_full do not want disruption from timer interrupts,
> >or other random system things. This includes block mq work.
> >
> >There is another issue with block mq vs. realtime
On 03/31/2015 08:27 AM, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not uncommon on systems that
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> CPUs with nohz_full do not want disruption from timer interrupts,
> or other random system things. This includes block mq work.
>
> There is another issue with block mq vs. realtime tasks that run
> 100% of the time, which is not
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not uncommon on systems that have CPUs
dedicated to real time use with
On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not uncommon on systems that have CPUs
dedicated to real time use with
On 03/31/2015 08:27 AM, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not uncommon on systems that
On 03/31/2015 09:33 AM, Frederic Weisbecker wrote:
On Tue, Mar 31, 2015 at 09:07:11AM -0600, Jens Axboe wrote:
On 03/31/2015 08:27 AM, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is
On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that run
100% of the time, which is not
On Tue, Mar 31, 2015 at 09:07:11AM -0600, Jens Axboe wrote:
On 03/31/2015 08:27 AM, Rik van Riel wrote:
CPUs with nohz_full do not want disruption from timer interrupts,
or other random system things. This includes block mq work.
There is another issue with block mq vs. realtime tasks that
28 matches
Mail list logo
