On Tue, 5 Jul 2016, Frederic Weisbecker wrote:
> > >>That's true, but I'd argue the behavior in that case should be that you
> > >>can
> > >>raise that kind of exception validly (so you can debug), and then you
> > >>should
> > >>quiesce on return to userspace so the application doesn't see
On Tue, 5 Jul 2016, Frederic Weisbecker wrote:
> > >>That's true, but I'd argue the behavior in that case should be that you
> > >>can
> > >>raise that kind of exception validly (so you can debug), and then you
> > >>should
> > >>quiesce on return to userspace so the application doesn't see
On Fri, Jul 01, 2016 at 04:59:26PM -0400, Chris Metcalf wrote:
> On 6/29/2016 11:18 AM, Frederic Weisbecker wrote:
> >
> >I just feel that quiescing, on the way back to user after an unwanted
> >interruption, is awkward. The quiescing should work once and for all
> >on return back from the prctl.
On Fri, Jul 01, 2016 at 04:59:26PM -0400, Chris Metcalf wrote:
> On 6/29/2016 11:18 AM, Frederic Weisbecker wrote:
> >
> >I just feel that quiescing, on the way back to user after an unwanted
> >interruption, is awkward. The quiescing should work once and for all
> >on return back from the prctl.
On 6/29/2016 11:18 AM, Frederic Weisbecker wrote:
On Fri, Jun 03, 2016 at 03:32:04PM -0400, Chris Metcalf wrote:
On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09,
On 6/29/2016 11:18 AM, Frederic Weisbecker wrote:
On Fri, Jun 03, 2016 at 03:32:04PM -0400, Chris Metcalf wrote:
On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09,
On Fri, Jun 03, 2016 at 03:32:04PM -0400, Chris Metcalf wrote:
> On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
> >I don't remember how much I answered this email, but I need to finish that
> >:-)
>
> Sorry for the slow response - it's been a busy week.
I'm certainly much slower ;-)
>
> >On
On Fri, Jun 03, 2016 at 03:32:04PM -0400, Chris Metcalf wrote:
> On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
> >I don't remember how much I answered this email, but I need to finish that
> >:-)
>
> Sorry for the slow response - it's been a busy week.
I'm certainly much slower ;-)
>
> >On
On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
I don't remember how much I answered this email, but I need to finish that :-)
Sorry for the slow response - it's been a busy week.
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On 5/25/2016 9:07 PM, Frederic Weisbecker wrote:
I don't remember how much I answered this email, but I need to finish that :-)
Sorry for the slow response - it's been a busy week.
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
I don't remember how much I answered this email, but I need to finish that :-)
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
> On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
> >On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> >> TL;DR: Let's make an explicit
I don't remember how much I answered this email, but I need to finish that :-)
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
> On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
> >On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> >> TL;DR: Let's make an explicit
On 4/22/2016 9:16 AM, Frederic Weisbecker wrote:
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
TL;DR: Let's make an explicit decision about whether task isolation
On 4/22/2016 9:16 AM, Frederic Weisbecker wrote:
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
TL;DR: Let's make an explicit decision about whether task isolation
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
> On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
> >On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> >> TL;DR: Let's make an explicit decision about whether task isolation
> >> should be "persistent" or "one-shot".
On Fri, Apr 08, 2016 at 12:34:48PM -0400, Chris Metcalf wrote:
> On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
> >On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> >> TL;DR: Let's make an explicit decision about whether task isolation
> >> should be "persistent" or "one-shot".
On 4/8/2016 12:34 PM, Chris Metcalf wrote:
However, this makes me wonder if "strict" mode should be the default
for task isolation?? That way task isolation really doesn't conflict
semantically with migration. And we could provide a "weak" mode, or a
"kernel-friendly" mode, or some such
On 4/8/2016 12:34 PM, Chris Metcalf wrote:
However, this makes me wonder if "strict" mode should be the default
for task isolation?? That way task isolation really doesn't conflict
semantically with migration. And we could provide a "weak" mode, or a
"kernel-friendly" mode, or some such
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> TL;DR: Let's make an explicit decision about whether task isolation
> should be "persistent" or "one-shot". Both have some advantages.
> =
>
> An important high-level issue
On 4/8/2016 9:56 AM, Frederic Weisbecker wrote:
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> TL;DR: Let's make an explicit decision about whether task isolation
> should be "persistent" or "one-shot". Both have some advantages.
> =
>
> An important high-level issue
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> Frederic,
>
> Thanks for the detailed feedback on the task isolation stuff.
>
> This reply kind of turned into an essay, so I've added a little "TL;DR"
> sentence before each section.
I think I'm going to cut my reply into several
On Wed, Mar 09, 2016 at 02:39:28PM -0500, Chris Metcalf wrote:
> Frederic,
>
> Thanks for the detailed feedback on the task isolation stuff.
>
> This reply kind of turned into an essay, so I've added a little "TL;DR"
> sentence before each section.
I think I'm going to cut my reply into several
Frederic,
Thanks for the detailed feedback on the task isolation stuff.
This reply kind of turned into an essay, so I've added a little "TL;DR"
sentence before each section.
TL;DR: Let's make an explicit decision about whether task isolation
should be "persistent" or "one-shot". Both
Frederic,
Thanks for the detailed feedback on the task isolation stuff.
This reply kind of turned into an essay, so I've added a little "TL;DR"
sentence before each section.
TL;DR: Let's make an explicit decision about whether task isolation
should be "persistent" or "one-shot". Both
On Thu, Feb 11, 2016 at 02:24:25PM -0500, Chris Metcalf wrote:
> On 01/30/2016 04:11 PM, Frederic Weisbecker wrote:
> >We have reverted the patch that made isolcpus |= nohz_full. Too
> >many people complained about unusable machines with NO_HZ_FULL_ALL
> >
> >But the user can still set that
On Thu, Feb 11, 2016 at 02:24:25PM -0500, Chris Metcalf wrote:
> On 01/30/2016 04:11 PM, Frederic Weisbecker wrote:
> >We have reverted the patch that made isolcpus |= nohz_full. Too
> >many people complained about unusable machines with NO_HZ_FULL_ALL
> >
> >But the user can still set that
On 01/30/2016 04:11 PM, Frederic Weisbecker wrote:
On Fri, Jan 29, 2016 at 01:18:05PM -0500, Chris Metcalf wrote:
On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
You asked what happens if nohz_full= is given as well, which is a
On 01/30/2016 04:11 PM, Frederic Weisbecker wrote:
On Fri, Jan 29, 2016 at 01:18:05PM -0500, Chris Metcalf wrote:
On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
You asked what happens if nohz_full= is given as well, which is a
On Fri, Jan 29, 2016 at 01:18:05PM -0500, Chris Metcalf wrote:
> On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
> >On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> >>You asked what happens if nohz_full= is given as well, which is a very
> >>good question. Perhaps the right
On Fri, Jan 29, 2016 at 01:18:05PM -0500, Chris Metcalf wrote:
> On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
> >On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> >>You asked what happens if nohz_full= is given as well, which is a very
> >>good question. Perhaps the right
On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
You asked what happens if nohz_full= is given as well, which is a very
good question. Perhaps the right answer is to have an early_initcall
that suppresses task isolation on any
On 01/27/2016 07:28 PM, Frederic Weisbecker wrote:
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
You asked what happens if nohz_full= is given as well, which is a very
good question. Perhaps the right answer is to have an early_initcall
that suppresses task isolation on any
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> On 01/19/2016 10:42 AM, Frederic Weisbecker wrote:
> >>+/*
> >>+ * Isolation requires both nohz and isolcpus support from the scheduler.
> >>+ * We provide a boot flag that enables both for now, and which we can
> >>+ * add other
On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> On 01/19/2016 10:42 AM, Frederic Weisbecker wrote:
> >>+/*
> >>+ * Isolation requires both nohz and isolcpus support from the scheduler.
> >>+ * We provide a boot flag that enables both for now, and which we can
> >>+ * add other
The existing nohz_full mode is designed as a "soft" isolation mode
that makes tradeoffs to minimize userspace interruptions while
still attempting to avoid overheads in the kernel entry/exit path,
to provide 100% kernel semantics, etc.
However, some applications require a "hard" commitment from
The existing nohz_full mode is designed as a "soft" isolation mode
that makes tradeoffs to minimize userspace interruptions while
still attempting to avoid overheads in the kernel entry/exit path,
to provide 100% kernel semantics, etc.
However, some applications require a "hard" commitment from
36 matches
Mail list logo
