我正在为一个func成像,这需要很长时间才能完成,比如远程服务器上的写操作,我在想是否有办法理解何时(至少哪一行)正在执行该任务的线程正在执行上下文切换,因为必须执行等待很长时间的另一个任务.
对不起,如果你看起来似乎是一个愚蠢的问题,或者我在试图解释上述内容时犯了错误
编辑：
我正在谈论调度程序自动请求发生的上下文切换.所以想象一下,我们处于这个长函数的中间,它执行大量操作并且调度程序给这个任务一个秒,例如10秒为了完成它.如果进程耗尽时间并且没有结束任务,它将被挂起,例如线程将执行另一个进程的另一个任务.当它结束时,调度程序可能会考虑再次尝试挂起的作业,执行将从它被挂起的地方开始恢复(因此将从PC寄存器读取值并继续)
你绝对可以得到你所要求的东西,但我觉得它对你的影响远远小于你所认为的.大多数(广泛的,巨大的！)大多数上下文切换都会发生在您可能会认为“无趣”的点上. lstat64(),mach_vm_map_trap(),mach_msg_trap(),mach_port_insert_member_trap(),kevent_id(),列表继续.大多数线程大部分时间都花在OS堆栈中. “远程服务器上的写操作”在需要很长时间后才会阻塞.它将主动阻止自己,因为它知道它将需要一个(令人难以置信的)很长一段时间.即便如此,你当然可以用仪器探索这个.只需选择系统跟踪配置文件,它将显示所有线程和系统核心,以及您的线程和设备上的所有其他线程如何安排,每次系统调用等等.这是大量的信息,所以你通常一次只能查看几秒钟.但它看起来像这样：
如果您处于上下文切换是主要瓶颈的位置,这是有用的信息.如果您正在处理过多的锁争用,或者由于您不断被其他线程中断而使您的L1缓存颠簸,则可能会发生这种情况.因此,如果你有一些线程,你希望它能够持续运行,并且它被阻止,这是非常有价值的信息.或者如果你有两个线程,你认为应该顺利地来回工作,但它们似乎在战斗(快速切换),那么你可以继续努力. (但这很少是你寻找性能调优的第一个地方,除非你正在处理相当低级的代码.)
根据您的描述,我认为您可能对调度程序有错误的想法.调度程序中的任何内容都不会超过10秒.在调度程序世界中,毫秒是很多时间.你应该考虑微秒甚至纳秒的事情.如果您正在处理假设从RAM中获取数据是免费的代码,那么您的时间尺度会错误. A network call is so ludicrously slow that you can basically estimate it as “forever.”在上下文切换级别,您正在查看以下事件：
00:00.770.247 Virtual memory Zero Fill took 10.50 µs small_free_list_add_ptr ← (31 other frames)