Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1341168 > unrolled thread
| Started by | Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |
|---|---|
| First post | 2016-02-24 00:30 +0100 |
| Last post | 2016-02-27 16:10 +0100 |
| Articles | 2 on this page of 42 — 8 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[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
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-02-29 11:10 +0100 |
| Subject | Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread |
| Message-ID | <r7sW7-1Bj-21@gated-at.bofh.it> |
| In reply to | #1345061 |
On Sat, Feb 27, 2016 at 10:35:28AM -0800, Linus Torvalds wrote:
> On Sat, Feb 27, 2016 at 6:58 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Paul's patches have the following structure:
> >
> > struct thread_local_abi {
> > union {
> > struct {
> > u32 cpu_id;
> > u32 seq;
> > };
> > u64 cpu_seq;
> > };
> > unsigned long post_commit_ip;
> > };
>
> Please don't do "unsigned long" in ABI structures any more.
>
> Make it u64, and make sure it is 64-bit aligned (which it would be in
> this case). Make it so that we don't have to have separate compat
> paths.
Yes, for sure. I was 'only' trying to reflect the state of the last rseq
patches. But yes, I should have called that out and avoided 'confusion'.
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2016-02-27 16:10 +0100 |
| Message-ID | <r6OFk-4PW-29@gated-at.bofh.it> |
| In reply to | #1345021 |
On February 27, 2016 6:15:01 AM PST, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>----- On Feb 27, 2016, at 1:24 AM, H. Peter Anvin hpa@zytor.com wrote:
>
>> On 02/26/16 16:40, Mathieu Desnoyers wrote:
>>>>
>>>> I think it would be a good idea to make this a general pointer for
>the kernel to
>>>> be able to write per thread state to user space, which obviously
>can't be done
>>>> with the vDSO.
>>>>
>>>> This means the libc per thread startup should query the kernel for
>the size of
>>>> this structure and allocate thread local data accordingly. We can
>then grow
>>>> this structure if needed without making the ABI even more complex.
>>>>
>>>> This is more than a system call: this is an entirely new way for
>userspace to
>>>> interact with the kernel. Therefore we should make it a general
>facility.
>>>
>>> I'm really glad to see I'm not the only one seeing potential for
>>> genericity here. :-) This is exactly what I had in mind
>>> last year when proposing the thread_local_abi() system call:
>>> a generic way to register an extensible per-thread data structure
>>> so the kernel can communicate with user-space and vice-versa.
>>>
>>> Rather than having the libc query the kernel for size of the
>structure,
>>> I would recommend that libc tells the kernel the size of the
>thread-local
>>> ABI structure it supports. The idea here is that both the kernel and
>libc
>>> need to know about the fields in that structure to allow a two-way
>>> interaction. Fields known only by either the kernel or userspace
>>> are useless for a given thread anyway. This way, libc could
>statically
>>> define the structure.
>>
>> Big fat NOPE there. Why? Because it means that EVERY interaction
>with
>> this memory, no matter how critical, needs to be conditionalized.
>> Furthermore, userspace != libc. Applications or higher-layer
>libraries
>> might have more information than the running libc about additional
>> fields, but with your proposal libc would gate them.
>
>Good point!
>
>>
>> As far as the kernel providing the size in the structure (alone) -- I
>> *really* hope you can see what is wrong with that!! That doesn't
>mean
>> we can't provide it in the structure as well, and that too might
>avoid
>> the skipped libc problem.
>
>Indeed, libc would need to query the size before it can allocate
>the structure.
>
>>
>>> I would be tempted to also add "features" flags, so both user-space
>>> and the kernel could tell each other what they support: user-space
>>> would announce the set of features it supports, and it could also
>>> query the kernel for the set of supported features. One simple
>approach
>>> would be to use a uint64_t as type for those feature flags, and
>>> reserve the last bit for extending to future flags if we ever have
>>> more than 64.
>>>
>>> Thoughts ?
>>
>> It doesn't seem like it would hurt, although the size of the flags
>field
>> could end up being an issue.
>
>I'm concerned that this thread-local ABI structure may become messy.
>Let's just imagine how we would first introduce a "cpu_id" field
>(int32_t),
>and eventually add a "seqnum" field for rseq in the future (unsigned
>long).
>
>Both fields need to be read with single-copy semantics as volatile
>reads, and both need to be naturally aligned. However, I'm tempted
>to use the "packed" attribute on the structure since it's an ABI
>between kernel and user-space. A pretty bad example of what this
>could become, due to alignment constraints, looks like:
>
>/* This structure needs to be aligned on pointer size. */
>struct thread_local_abi {
> int32_t cpu_id;
> int32_t __unused1;
> unsigned long seqnum;
> /* Add new fields at the end. */
>} __attribute__((packed));
>
>And this is just a start. It may become messier as we append
>new fields in the future.
>
>The main argument I currently see in favor of having this
>meta system call for all per-thread features is to only
>maintain a single pointer in the kernel task_struct rather
>than one per thread-local feature.
>
>If the goal is really to keep the burden on the task struct
>small, we could use kmalloc()/kfree() to allocate and free an
>array of pointers to the various per-thread features, rather
>than putting them directly in task_struct. We could keep a
>mask of the enabled features in the task struct too (which
>we will likely have to do even if we go the the thread-local
>ABI meta system call).
>
>Having this per-task allocated pointer array at kernel-level
>would allow us to have one system call per feature, with clear
>semantics, without evolving a messy thread-local ABI structure
>due to all sorts of alignment constraints.
>
>Thoughts ?
>
>Thanks,
>
>Mathieu
I think you are worried about problems which we have already solved many, many times - structures are very common in the user space ABI and we know how to deal with this.
And when you say:
> However, I'm tempted
> to use the "packed" attribute on the structure
> since it's an ABI
> between kernel and user-space.
and mention "unsigned long" in a user space ABI all I can think of that you really have not followed the issues of user space ABI design as they have evolved over the last 20 years.
Simply put: non-problem.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web