Messages in this thread | | | Date | Wed, 10 Aug 2016 17:40:39 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH v7 1/7] Restartable sequences system call |
| |
----- On Aug 10, 2016, at 4:01 AM, Andy Lutomirski luto@amacapital.net wrote:
> On Tue, Aug 9, 2016 at 9:13 AM, Boqun Feng <boqun.feng@gmail.com> wrote:
<snip>
> >> However, I'm thinking maybe we can use some tricks to avoid unnecessary >> aborts-on-preemption. >> >> First of all, I notice we haven't make any constraint on what kind of >> memory objects could be "protected" by rseq critical sections yet. And I >> think this is something we should decide before adding this feature into >> kernel. >> >> We can do some optimization if we have some constraints. For example, if >> the memory objects inside the rseq critical sections could only be >> modified by userspace programs, we therefore don't need to abort >> immediately when userspace task -> kernel task context switch. > > True, although trying to do a syscall in an rseq critical section > seems like a bad idea in general.
The scenario above does not require the rseq critical section to perform an explicit system call. It can happen from simple timer-driven preemption of user-space.
<snip>
> > But do we need to protect MAP_SHARED objects? If not, maybe we could > only track context switches between different tasks sharing the same > mm.
I have tracing use-cases involving MAP_SHARED objects for rseq: per-cpu buffers.
Moreover, if you only track context switch between tasks with the same mm, you run into issues if you have:
Process A Thread 1 (rseq) Thread 2 (rseq)
Process B Thread 1
Scheduling: A.1 -> B.1 -> A.2 -> B.1 -> A.1
There is no scheduling between threads of the same process here, but the entire chain involves two threads of the same process accessing the same per-cpu data concurrently.
Thanks,
Mathieu
> > --Andy
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |