lkml.org 
[lkml]   [2016]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread
    ----- On Feb 27, 2016, at 7:57 PM, Linus Torvalds torvalds@linux-foundation.org wrote:

    > On Sat, Feb 27, 2016 at 4:39 PM, Mathieu Desnoyers
    > <mathieu.desnoyers@efficios.com> wrote:
    >>
    >>
    >> I'm particularly interested to know what are the best practices to
    >> deal with an extensible bitfield (the features mask). cpu_set_t
    >> and sigmask each seem to do their own thing.
    >
    > Quite frankly, why would the kernel ever touch anything else?
    >
    > And if the kernel doesn't touch anything else, why make it part of the ABI?
    >
    > I don't see why the kernel would ever want to have a more complex
    > interface. Explain.

    The part of ABI I'm trying to express here is for discoverability
    of available features by user-space. For instance, a kernel
    could be configured with "CONFIG_RSEQ=n", and userspace should
    not rely on the rseq fields of the thread-local ABI in that case.

    The initial idea I had was to populate a mask of available features
    (hence my question above), but now that I think about it, we could
    perhaps have a "query" system call receiving a "feature number", no
    mask needed then. E.g.:

    enum thread_local_abi_features {
    THREAD_LOCAL_FEATURE_CPU_ID = 0,
    THREAD_LOCAL_FEATURE_RSEQ = 1,
    /* Add future features here. */
    };

    int thread_local_abi_feature(uint64_t feature);

    Another option would be to rely on specific "uninitialized"
    values for each feature in struct thread_local_abi (e.g. -1
    for cpu_id). We may need to reserve extra space for
    "feature enabled" booleans in cases where the uninitialized
    value is also used when initialized (e.g. a sequence counteR).
    The advantage of using the uninitialized value and/or the
    "boolean" within the struct thread_local_abi is that testing
    whether the feature is active can be done by reading from
    the same cache-line as when using the feature (in user-space).

    Not sure what would be the best option here.

    Thoughts ?

    Thanks,

    Mathieu

    --
    Mathieu Desnoyers
    EfficiOS Inc.
    http://www.efficios.com

    \
     
     \ /
      Last update: 2016-02-28 16:01    [W:3.398 / U:1.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site