Hacker News Reader

Comment by acqq | Hacker News Reader

> I've seen some

Then please quote at least one actually used in Linux kernel, including where it is used.

I didn't say I've seen those in the kernel. I haven't ever looked at the spin lock(s) in the kernel.

And your claims are still completely unsupported, at least here in this discussion. You don't give even a single example of some other publicly known code that does what .NET does. And the way you formulated your previous claim appeared to claim that the Linux kernel contains such a kind of code. I'd still appreciate even a single verifiable example of all that "some" that you've apparently "seen".

There exist spink locks outside of the Linux kernel

Yes, but the Linux kernel is the one I'm more familiar with. So I looked for another example: glibc's pthread_mutex_lock. The code is at nptl/pthread_mutex_lock.c and the "pause" instruction here is called atomic_spin_nop() (or BUSY_WAIT_NOP on older versions), defined by sysdeps/x86_64/atomic-machine.h. Yet again, it does a single "pause" instruction in the loop, and the loop condition tests the lock.

The kernel does use PAUSE // f390

objdump -d vmlinux.o | grep -c "f3 90"

245

e.g.

00000000000683a0 <__task_rq_lock>:

   683a0:       e8 00 00 00 00          callq  683a5 <__task_rq_lock+0x5>
   683a5:       55                      push   %rbp
   683a6:       48 89 e5                mov    %rsp,%rbp
   683a9:       41 56                   push   %r14
   683ab:       49 c7 c6 00 00 00 00    mov    $0x0,%r14
   683b2:       41 55                   push   %r13
   683b4:       49 89 fd                mov    %rdi,%r13
   683b7:       41 54                   push   %r12
   683b9:       53                      push   %rbx
   683ba:       48 c7 c3 00 00 00 00    mov    $0x0,%rbx
   683c1:       41 8b 45 3c             mov    0x3c(%r13),%eax
   683c5:       4d 8b 24 c6             mov    (%r14,%rax,8),%r12
   683c9:       49 01 dc                add    %rbx,%r12
   683cc:       4c 89 e7                mov    %r12,%rdi
   683cf:       e8 00 00 00 00          callq  683d4 <__task_rq_lock+0x34>
   683d4:       41 8b 45 3c             mov    0x3c(%r13),%eax
   683d8:       49 8b 14 c6             mov    (%r14,%rax,8),%rdx
   683dc:       48 01 da                add    %rbx,%rdx
   683df:       49 39 d4                cmp    %rdx,%r12
   683e2:       75 13                   jne    683f7 <__task_rq_lock+0x57>
   683e4:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   683e9:       74 0c                   je     683f7 <__task_rq_lock+0x57>
   683eb:       5b                      pop    %rbx
   683ec:       4c 89 e0                mov    %r12,%rax
   683ef:       41 5c                   pop    %r12
   683f1:       41 5d                   pop    %r13
   683f3:       41 5e                   pop    %r14
   683f5:       5d                      pop    %rbp
   683f6:       c3                      retq   
   683f7:       4c 89 e7                mov    %r12,%rdi
   683fa:       e8 00 00 00 00          callq  683ff <__task_rq_lock+0x5f>
   683ff:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   68404:       75 bb                   jne    683c1 <__task_rq_lock+0x21>
   68406:       f3 90                   pause  
   68408:       41 83 7d 60 02          cmpl   $0x2,0x60(%r13)
   6840d:       75 b2                   jne    683c1 <__task_rq_lock+0x21>
   6840f:       eb f5                   jmp    68406 <__task_rq_lock+0x66>
   68411:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
   68416:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
   6841d:       00 00 00

that pause should be:

                  while (unlikely(task_on_rq_migrating(p)))                       
                          cpu_relax();                                            

   -ss

That answer with the long unnecessary dump completely misses what I asked for.

I've never disputed that kernel uses pause (of course it does), but the claim of eloff which he states in the post to which I reply:

"where it starts off with one pause instruction, then goes to multiple, then moves to more drastic back-off techniques"

That's what appears that eloff claims in his post, that he has

"seen some"

where he effectively disputes the previous claim of cesarb: "it's a loop over the pause instruction, but the loop condition checks the lock value"

Your example doesn't support the claim of eloff, and supports the claim of cesarb:

https://elixir.bootlin.com/linux/v4.2/source/kernel/sched/sc...

That is, it checks the external condition after each pause. Which can't produce the problems that .NET produced.

And that's why I had expected eloff to give even one example that supports his claim, since what I can find is only what cesarb claims "it's a loop over the pause instruction, but the loop condition checks the lock value"

The whole thread is about if the loop is containing pause, but without the checks of the external condition (but instead just with the counter, like in the offending .NET example from the original article) exists in Linux kernel. If somebody claims that the .NET implementation is not unique in its carelessness of using just a big counter loop over the pause (which appears to be to me: that .NET does something unexpected) (s)he should support that.

(That I ask for the support for "extraordinary claim" in the thread where only one side makes it should be understood, but it seems some here vote "down" without understanding what is being discussed at all -- it's absurd having to summarize the whole discussion in the reply to the "extraordinary claim" in which I for the evidence)

> That answer with the long unnecessary dump completely misses what I asked for.

Yeah, I guess you are right. Sorry for the noise.

/* p.s. I didn't vote down your comment */

Reply on news.ycombinator.com