3 ms·

The accept call on Linux: - invokes the accept() function of the socket family: https://github.com/torvalds/linux/blob/be779f03d563981c65cc7417cc5e0dbbc5b89d30

by _wmd 8y ago

The accept call on Linux: - invokes the accept() function of the socket family: https://github.com/torvalds/linux/blob/be779f03d563981c65cc7417cc5e0dbbc5b89d30/net/socket.c#L1635 https://github.com/torvalds/linux/blob/be779f03d563981c65cc7... - which invokes the accept() function of the protocol: https://github.com/torvalds/linux/blob/be779f03d563981c65cc7417cc5e0dbbc5b89d30/net/ipv4/inet_connection_sock.c#L425 https://github.com/torvalds/linux/blob/be779f03d563981c65cc7... - which invokes lock_sock_nested(), which spins https://github.com/torvalds/linux/blob/be779f03d563981c65cc7417cc5e0dbbc5b89d30/net/core/sock.c#L2847 https://github.com/torvalds/linux/blob/be779f03d563981c65cc7...

dragontamer 8y ago
The accept call sleeps if no sockets are available. The thread goes to sleep entirely and stops executing on the core completely. Yes, there are spin-locks involved in the process. But I'm talking about these lines of code: > error = inet_csk_wait_for_connect(sk, timeo); > mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_); Etc. etc. You know, the stuff that causes milliseconds to multiple-seconds worth of delay, as opposed to "pause / spinlocks" which is measured in nanoseconds.
- _wmd 8y ago
  The parent context asked what code could have 40 cores spinning, I picked the first example I could think of. You said it wasn't a spinlock, it was. Sure there is a followup lock that sleeps for the empty-queue case, but that doesn't relate to OP's question You can find similar behaviour in the filesystem APIs, anything touching the VM (mmap_sem IIRC is also a spinlock), pretty much any OS API where threads are all banging at the same shared resource that isn't expected to require a long wait. struct file also contains a spinlock, but doesn't look like it's used in normal operation
  - dragontamer 8y ago
    > The parent context asked what code could have 40 cores spinning, I picked the first example I could think of. Hmmm... okay. I think I see what you're going for. I think its a bit of a muddy example though because of the mutex. But pre-mutex, there's definitely a spinlock, and the 40-cores would definitely hit that first. Mutexes themselves are likely a spinlock as well, so there's a chance (a low-chance... but a chance nonetheless) that everything is fast-pathed and never sleeps a thread. So yeah, there are better examples you could use. But upon further analysis, it does seem like your example does work with the right frame of mind.

by _wmd 8y ago

dragontamer 8y ago

The accept call sleeps if no sockets are available. The thread goes to sleep entirely and stops executing on the core completely. Yes, there are spin-locks involved in the process. But I'm talking about these lines of code: > error = inet_csk_wait_for_connect(sk, timeo); > mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_); Etc. etc. You know, the stuff that causes milliseconds to multiple-seconds worth of delay, as opposed to "pause / spinlocks" which is measured in nanoseconds.

_wmd 8y ago
The parent context asked what code could have 40 cores spinning, I picked the first example I could think of. You said it wasn't a spinlock, it was. Sure there is a followup lock that sleeps for the empty-queue case, but that doesn't relate to OP's question You can find similar behaviour in the filesystem APIs, anything touching the VM (mmap_sem IIRC is also a spinlock), pretty much any OS API where threads are all banging at the same shared resource that isn't expected to require a long wait. struct file also contains a spinlock, but doesn't look like it's used in normal operation
- dragontamer 8y ago
  > The parent context asked what code could have 40 cores spinning, I picked the first example I could think of. Hmmm... okay. I think I see what you're going for. I think its a bit of a muddy example though because of the mutex. But pre-mutex, there's definitely a spinlock, and the 40-cores would definitely hit that first. Mutexes themselves are likely a spinlock as well, so there's a chance (a low-chance... but a chance nonetheless) that everything is fast-pathed and never sleeps a thread. So yeah, there are better examples you could use. But upon further analysis, it does seem like your example does work with the right frame of mind.