Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1345286

Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread

From Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Newsgroups linux.kernel
Subject Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread
Date 2016-02-28 15:40 +0100
Message-ID <r7aFQ-3MT-5@gated-at.bofh.it> (permalink)
References (3 earlier) <r6RWy-76H-13@gated-at.bofh.it> <r6WWe-23d-1@gated-at.bofh.it> <r6XSi-2Hj-9@gated-at.bofh.it> <r6XSi-2Hj-11@gated-at.bofh.it> <r6XSi-2Hj-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


----- 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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 00:30 +0100
  Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-24 12:20 +0100
    Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 18:20 +0100
    Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2016-02-26 00:40 +0100
      Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 18:50 +0100
  Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-25 11:00 +0100
    Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-25 18:00 +0100
      Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-25 18:10 +0100
        Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-25 18:20 +0100
          Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-26 12:40 +0100
            Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-26 17:40 +0100
              Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 18:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Thomas Gleixner <tglx@linutronix.de> - 2016-02-26 19:10 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-26 21:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 00:10 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-27 01:50 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 07:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-27 15:20 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-27 16:00 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-27 19:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 20:10 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-28 01:00 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 02:00 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-28 15:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-03-01 21:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-01 22:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-01 22:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-03-01 23:00 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-03-02 11:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:40 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Arnd Bergmann <arnd@arndb.de> - 2016-02-29 11:50 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-29 13:50 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread Arnd Bergmann <arnd@arndb.de> - 2016-02-29 14:20 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-29 19:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Geert Uytterhoeven <geert@linux-m68k.org> - 2016-03-02 11:50 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-03-01 19:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-03-01 19:50 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Geert Uytterhoeven <geert@linux-m68k.org> - 2016-02-28 14:10 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 17:30 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of  running thread Peter Zijlstra <peterz@infradead.org> - 2016-02-29 11:10 +0100
                Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread "H. Peter Anvin" <hpa@zytor.com> - 2016-02-27 16:10 +0100

csiph-web