On Thu, 8 Oct 2015, Andy Lutomirski wrote: > Will this really end up working? I can see two problems: > > 1. It's rather expensive. For processes that still make syscalls but > just not many, it means that you're forcibly quiescing every time. A process that does a lot of syscalls to networking must usually tolerate nose. Task isolation is for cases where there is no need of much support by the OS. > 2. It only really makes sense for work that results from local kernel > actions, happens once, and won't recur. I admit that I don't know how > many of the offenders are like this, but I can imagine there being > some periodic tasks that could be done locally or remotely with a big > percpu lock. The percpu data is used because critical code sections run faster with data that is not contended. Touching the data remotely causes performance regression. You do not want that unless the task will stay away for awhile from OS actions. > > Or simply ignore the situation until the cpu is entering the > > kernel again? > > Maybe. I wonder if, for things like vmstat, that would be better in > general (not just NOHZ). We have task_work nowadays... vmstat uses per cpu data that should be local on a processor for performance reasons. Doing remote write accessses will cause cache misses to occur and will result in performance issues. > > Caches can be useful later again when the process wants to > > allocate memory etc. We would have to repopulate them if we flush them. > > True. But we don't need to flush them at all until there's memory > pressure, and the big percpu lock solves this particular problem quite > nicely -- a remote CPU can simply drain the cache itself instead of > using an IPI. You still did not answer me as to why you would want them flushed at all. Memory reclaim can occur in a number of ways. No need to flush everything. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
