lkml.org 
[lkml]   [2015]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: crazy idea: big percpu lock (Re: task isolation)
    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.


    \
     
     \ /
      Last update: 2015-10-09 13:41    [W:2.729 / U:1.324 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site