On Thu, Jul 14, 2016 at 2:22 PM, Chris Metcalf <cmetcalf@xxxxxxxxxxxx> wrote: > On 7/14/2016 5:03 PM, Andy Lutomirski wrote: >> >> On Thu, Jul 14, 2016 at 1:48 PM, Chris Metcalf <cmetcalf@xxxxxxxxxxxx> >> 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 questionable. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
