On Thu, 14 Jul 2016, Andy Lutomirski wrote: > 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. But then vmalloc/vfre activity is not to be expected if user space only is running. Since the kernel is not active and this affects kernel address space only it could be deferred. Such events will cause OS activity that causes a number of high latency events but then the system will quiet down again. > On very brief inspection, __kmem_cache_shutdown will be a problem on > some workloads as well. These are all corner cases that can be worked on over time if they are significant. The main issue here is to reduce the obvious and relatively frequent causes for ticks and allow easier detection of events that cause tick activity. -- 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
