This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 06/14/2018 03:49 PM, Pavel Machek wrote:
Hi!- rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread flag, so rseq_handle_notify_resume() can check whether it's in a rseq critical section when returning to user-space, - rseq_signal_deliver(): on signal delivery, rseq_handle_notify_resume() checks whether it's in a rseq critical section, - rseq_migrate: on migration, the scheduler sets TIF_NOTIFY_RESUME as well,Yes, this is not likely to be noticeable. But the proposal wanted to add a syscall to thread creation, right? And I believe that may be noticeable.Fair point! Do we have a standard benchmark that would stress this ?Web server performance benchmarks basically test clone() performance in many cases.
Isn't that fork? I expect that the rseq arena is inherited on fork and fork-type clone, otherwise it's going to be painful.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |