Linux内核：立即取消调度的代价
来自 http://lkml.indiana.edu/hypermail/linux/ kernel/0103.1/0030.html 我了解了 linux 中的一种新型互斥体，adaptive_np 互斥体：
PTHRED_MUTEX_ADAPTIVE_NP 是一个新的 互斥体旨在用于高 吞吐量的牺牲 公平性，甚至 CPU 周期。这 互斥体不会将所有权转移给 等待线程，而是允许 竞赛。此外，通过 SMP 内核， 锁定操作使用旋转来 重试锁定以避免成本 立即取消安排。
提到了“立即取消调度的成本”。这个费用是多少？ （就CPU节拍而言；TLB、TSS、smth else重新加载）在“立即取消调度请求”和再次重新调度回运行状态之间，内核做了什么？
如何进行明确的取消调度以及如何衡量其成本？
From the http://lkml.indiana.edu/hypermail/linux/kernel/0103.1/0030.html I learn about a new type of mutexes in linux, an adaptive_np one:
The PTHRED_MUTEX_ADAPTIVE_NP is a new
mutex that is intended for high
throughput at the sacrifice of
fairness and even CPU cycles. This
mutex does not transfer ownership to a
waiting thread, but rather allows for
competition. Also, over an SMP kernel,
the lock operation uses spinning to
retry the lock to avoid the cost of
immediate descheduling.
There is mentioned "Cost of immediate descheduling". How much is this cost? (In terms of cpu ticks; TLB, TSS, smth else reloading) What is done in kernel between an "immediate descheduling request" and rescheduling back to the run state again?
How can I do a explicit descheduling and how can I measure its cost?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看起来它只是一个轻量级互锁，旨在允许线程避开调度程序。
这个想法是用自旋锁中花费的较短时间来取代相对繁重的基于上下文切换的操作。
忽略“新”的使用，自旋锁就像山一样古老。我想，大约 10 年前，pthread 库还是个新东西。
“显式取消调度”大概与上下文切换相同，因此您可以通过让两个线程
yield()相互使用 CPU 一百万次并测量运行时间来测量这一点。It looks like it's just a lightweight interlock intended to allow threads to avoid the scheduler.
The idea is to replace a relatively heavy context-switch-based operation with a hopefully-short period of time spent in a spinlock.
Disregard the use of "new", spinlocks are as old as the hills. It was, I guess, new to that pthread library almost 10 years ago.
An "explicit descheduling" is presumably the same thing as a context switch, so you could measure this by having two threads
yield()the CPU to each other a million times and measure the runtime.