[lkml]   [2016]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v13 00/12] support "task_isolation" mode
On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf <> wrote:
> On 7/14/2016 5:03 PM, Andy Lutomirski wrote:
>> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf <>
>> wrote:
>>> Here is a respin of the task-isolation patch set. This primarily
>>> reflects feedback from Frederic and Peter Z.
>> I still think this is the wrong approach, at least at this point. The
>> first step should be to instrument things if necessary and fix the
>> obvious cases where the kernel gets entered asynchronously.
> Note, however, that the task_isolation_debug mode is a very convenient
> way of discovering what is going on when things do go wrong for task
> isolation.
>> Only once
>> there's a credible reason to believe it can work well should any form
>> of strictness be applied.
> I'm not sure what criteria you need for this, though. Certainly we've been
> shipping our version of task isolation to customers since 2008, and there
> are quite a few customer applications in production that are working well.
> I'd argue that's a credible reason.
>> As an example, enough vmalloc/vfree activity will eventually cause
>> flush_tlb_kernel_range to be called and *boom*, there goes your shiny
>> production dataplane application.
> Well, that's actually a refinement that I did not inflict on this patch
> series.

Submit it separately, perhaps?

The "kill the process if it goofs" think while there are known goofs
in the kernel, apparently with patches written but unsent, seems

 \ /
  Last update: 2016-07-19 01:01    [W:0.090 / U:4.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site