Hi! > So for instance, this turns: > > int cpu = rseq_per_cpu_lock(lock, target_cpu); > [...] > rseq_per_cpu_unlock(lock, cpu); > > into > > int cpu = rseq_this_cpu_lock(lock); > [...] > rseq_per_cpu_unlock(lock, cpu); > > and: > > per_cpu_list_push(list, node, target_cpu); > [...] > per_cpu_list_pop(list, node, target_cpu); > > into > > this_cpu_list_push(list, node, &cpu); /* cpu is an output parameter. */ > [...] > node = this_cpu_list_pop(list, &cpu); /* cpu is an output parameter. */ > > Eventually integrating cpu_opv or some alternative will allow passing > the cpu number as parameter rather than requiring the algorithm to work > on the current CPU. > > The second effect of not having the cpu_opv fallback is that > line and instruction single-stepping with a debugger transforms rseq > critical sections based on retry loops into never-ending loops. > Debuggers need to use the __rseq_table section to skip those critical > sections in order to correctly behave when single-stepping a thread > which uses rseq in a retry loop. However, applications which use an > alternative fallback method rather than retrying on rseq fast-path abort > won't be affected by this kind of single-stepping issue. > > Thanks for your feedback! Would it make sense to include Documentation/ patch? I guess at least manpage describing the syscall will be needed.... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
