From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v13 00/12] support "task_isolation" mode Date: Thu, 14 Jul 2016 14:03:24 -0700 Message-ID: References: <1468529299-27929-1-git-send-email-cmetcalf@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1468529299-27929-1-git-send-email-cmetcalf-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Chris Metcalf Cc: Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Peter Zijlstra , Andrew Morton , Rik van Riel , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , Viresh Kumar , Catalin Marinas , Will Deacon , Daniel Lezcano , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux API , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-api@vger.kernel.org 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. Only once there's a credible reason to believe it can work well should any form of strictness be applied. 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. Once virtually mapped kernel stacks happen, the frequency with which this happens will only increase. On very brief inspection, __kmem_cache_shutdown will be a problem on some workloads as well. --Andy