Hey -
I think the ideas Daniel brings up here are interesting -- specifically the
notion that a thread could set a "pre-sleep wish" to signal it's sleeping. As
this conversation shows I think there's a fair bit of depth to that. For
example, the FUTEX_LOCK is an alternative approach. Another id
>>> int rseq(struct rseq * rseq, uint32_t rseq_len, int flags, uint32_t
>>>sig);
>>
>> Really dumb question -- and one I'm sorry to bring up at the last minute.
>> Should
>> we consider making the syscall name something more generic
>> "register_tls_abi"?
> I proposed that approach back
(apologies for the duplicate email, the previous one bounced as it was
accidentally using HTML formatting)
If I understand correctly this is run on every context switch so we probably
want to make it really fast
> +static int rseq_need_restart(struct task_struct *t, uint32_t cs_flags)
> +{
> +
> int rseq(struct rseq * rseq, uint32_t rseq_len, int flags, uint32_t
>sig);
Really dumb question -- and one I'm sorry to bring up at the last minute.
Should we consider making the syscall name something more generic
"register_tls_abi"? I'm assuming that if we ever want to use a per-threa
> if (!((long)ip - (long)start_ip <= (long)post_commit_offset))
> return 1;
> This introduces an issue here: if "ip" is lower than "start_ip", we
> can incorrectly think we are in a critical section, when we are in
> fact not.
This shouldn't be an issue if we used unsigned numbers. Eg if start_
> The layout of struct rseq_cs is as follows:
> start_ip
> Instruction pointer address of the first instruction of the
> sequence of consecutive assembly instructions.
> post_commit_ip
> Instruction pointer address after the last instruction of
> the sequence of consecutive assembly instructio
> I have a use-case for keeping the reference counting in place though. It's
> use of rseq in signal handlers.
Would this be solved by saying that the rseq api will return an error if you
register and there's already a block registered. In this case the signal
handler would register the rseq abi
Hey,
> So far the restrictions I see for libraries using this symbol are:
> - They should never be unloaded,
> - They should never be loaded with dlopen RTLD_LOCAL flag.
We talked a bit about this off-list but I wanted to state publicly that I think
this model works well for our use case. Specif
Hey,
I'm really excited to hear that you're open to this patch set and totally
understand the desire for some more numbers. I have a few thoughts and
questions -- hopefully ones that could help better understand where you'd like
to see more data (potentially from myself and other Facebook folks
On 8/25/16, 10:08 AM, "Mathieu Desnoyers"
wrote:
> The most appealing application we have so far is Dave Watson's Facebook
>services using jemalloc as a memory allocator. It would be nice if he
>could re-run those benchmarks with my rseq implementation. The trade-offs
>here are about
Mathieu Desnoyers wrote:
> Expose a new system call allowing threads to register a userspace memory
> area where to store the current CPU number. Scheduler migration sets the
I really like that this approach makes it easier to add a per-thread
interaction between userspace and the kernel in the f
11 matches
Mail list logo
