- On Apr 7, 2016, at 12:43 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Thu, Apr 7, 2016 at 8:53 AM, Peter Zijlstra wrote:
>> On Thu, Apr 07, 2016 at 08:44:38AM -0700, Andy Lutomirski wrote:
>>> On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote:
>>> > On Thu, Apr 07, 2016 at 07:35:
- On Apr 8, 2016, at 5:25 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Apr 8, 2016 at 10:46 AM, Mathieu Desnoyers
> wrote:
>>
>> By the way, the debugger can always decide to single-step through the
>> first iteration of the rseq, and then after it loops, decide to skip
On Fri, Apr 8, 2016 at 10:46 AM, Mathieu Desnoyers
wrote:
>
> By the way, the debugger can always decide to single-step through the
> first iteration of the rseq, and then after it loops, decide to skip
> single-stepping until the exit points are reached.
A _human_ debugger may decide to do that
On Apr 8, 2016 10:46 AM, "Mathieu Desnoyers"
wrote:
>
> - On Apr 7, 2016, at 10:05 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On Apr 7, 2016, at 9:21 PM, Andy Lutomirski l...@amacapital.net wrote:
> >
> >> On Thu, Apr 7, 2016 at 6:11 PM, Mathieu Desnoyers
> >>
- On Apr 7, 2016, at 10:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 7, 2016, at 9:21 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>> On Thu, Apr 7, 2016 at 6:11 PM, Mathieu Desnoyers
>> wrote:
>>> - On Apr 7, 2016, at 6:05 PM, Andy Lutomirski l...@a
On Apr 7, 2016 11:41 PM, "Peter Zijlstra" wrote:
>
> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
> > enter the critical section:
> > 1:
> > movq %[cpu], %%r12
> > movq {address of counter for our cpu}, %%r13
> > movq {some fresh value}, (%%r13)
> > cmpq %[cpu], %%r12
> > jne 1
On Apr 8, 2016 4:04 AM, "Peter Zijlstra" wrote:
>
> On Thu, Apr 07, 2016 at 03:05:26PM -0700, Andy Lutomirski wrote:
>
> > It doesn't, which is what I like about my variant. If the thread
> > accesses the protected data structure, though, it should bump the
> > sequence count, which will cause th
On Thu, Apr 07, 2016 at 03:05:26PM -0700, Andy Lutomirski wrote:
> It doesn't, which is what I like about my variant. If the thread
> accesses the protected data structure, though, it should bump the
> sequence count, which will cause the first thread to about when it
> gets scheduled in.
Nope i
On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
> enter the critical section:
> 1:
> movq %[cpu], %%r12
> movq {address of counter for our cpu}, %%r13
> movq {some fresh value}, (%%r13)
> cmpq %[cpu], %%r12
> jne 1b
This is inherently racy; your forgot the detail of 'some fresh va
- On Apr 7, 2016, at 9:21 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Thu, Apr 7, 2016 at 6:11 PM, Mathieu Desnoyers
> wrote:
>> - On Apr 7, 2016, at 6:05 PM, Andy Lutomirski l...@amacapital.net wrote:
>>
>>> On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote:
On Thu, Apr
On Thu, Apr 7, 2016 at 6:11 PM, Mathieu Desnoyers
wrote:
> - On Apr 7, 2016, at 6:05 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>> On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote:
>>> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
> [...]
>>>
it's inherently
- On Apr 7, 2016, at 6:05 PM, Andy Lutomirski l...@amacapital.net wrote:
> On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote:
>> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
[...]
>>
>>> it's inherently debuggable,
>>
>> It is more debuggable, agreed.
>>
>>> and it allo
On Thu, Apr 7, 2016 at 1:11 PM, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
>> More concretely, this looks like (using totally arbitrary register
>> assingments -- probably far from ideal, especially given how GCC's
>> constraints work):
>>
>> enter the
On Thu, Apr 07, 2016 at 09:43:33AM -0700, Andy Lutomirski wrote:
> More concretely, this looks like (using totally arbitrary register
> assingments -- probably far from ideal, especially given how GCC's
> constraints work):
>
> enter the critical section:
> 1:
> movq %[cpu], %%r12
> movq {address
On Thu, Apr 7, 2016 at 8:53 AM, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 08:44:38AM -0700, Andy Lutomirski wrote:
>> On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote:
>> > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
>> >> What I meant was: rather than shoving indiv
On Thu, Apr 07, 2016 at 08:44:38AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote:
> > On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
> >> What I meant was: rather than shoving individual values into the TLABI
> >> thing, shove in a pointer:
On Thu, Apr 7, 2016 at 8:24 AM, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
>> What I meant was: rather than shoving individual values into the TLABI
>> thing, shove in a pointer:
>>
>> struct commit_info {
>> u64 post_commit_rip;
>> u32 cpu;
>> u
On Thu, Apr 07, 2016 at 05:24:32PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
> > That way we could take an async signal, handle it, and resume, even in
> > the middle of a commit, without aborting. Of course, if the signal
> > hander tried to a
On Thu, Apr 07, 2016 at 07:35:26AM -0700, Andy Lutomirski wrote:
> What I meant was: rather than shoving individual values into the TLABI
> thing, shove in a pointer:
>
> struct commit_info {
> u64 post_commit_rip;
> u32 cpu;
> u64 *event;
> // whatever else;
> };
>
> and then put a commi
On Apr 7, 2016 5:02 AM, "Peter Zijlstra" wrote:
>
> On Wed, Apr 06, 2016 at 08:56:33AM -0700, Andy Lutomirski wrote:
> > What are the useful commit operations? IIUC they probably need to be
> > single instructions, which makes it sound like they're all either RMW
> > or store operations. I think
On Wed, Apr 06, 2016 at 08:56:33AM -0700, Andy Lutomirski wrote:
> What are the useful commit operations? IIUC they probably need to be
> single instructions, which makes it sound like they're all either RMW
> or store operations. I think that plain stores are sufficient to
> emulate RMW since (1
On Oct 27, 2015 4:56 PM, "Paul Turner" wrote:
>
> This is an update to the previously posted series at:
> https://lkml.org/lkml/2015/6/24/665
>
> Dave Watson has posted a similar follow-up which allows additional critical
> regions to be registered as well as single-step support at:
> https://
- On Dec 11, 2015, at 7:05 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Oct 27, 2015, at 7:56 PM, Paul Turner commo...@gmail.com wrote:
>
>> This is an update to the previously posted series at:
>> https://lkml.org/lkml/2015/6/24/665
>>
>> Dave Watson has posted a
- On Oct 27, 2015, at 7:56 PM, Paul Turner commo...@gmail.com wrote:
> This is an update to the previously posted series at:
> https://lkml.org/lkml/2015/6/24/665
>
> Dave Watson has posted a similar follow-up which allows additional critical
> regions to be registered as well as single-step
On 10/27/15 04:56 PM, Paul Turner wrote:
> This series is a new approach which introduces an alternate ABI that does not
> depend on open-coded assembly nor a central 'repository' of rseq sequences.
> Sequences may now be inlined and the preparatory[*] work for the sequence can
> be written in a hi
This is an update to the previously posted series at:
https://lkml.org/lkml/2015/6/24/665
Dave Watson has posted a similar follow-up which allows additional critical
regions to be registered as well as single-step support at:
https://lkml.org/lkml/2015/10/22/588
This series is a new approach
26 matches
Mail list logo
