linux 进程调度到cpu,在多核机器Linux OS中,当进程调度程序将一个进程迁移到另一个cpu时...

RSS is 65G,when call fork,sys_clone->dup_mm->copy_page_range will consume more than 2 seconds

在执行fork(或clone)时,应将现有进程的vmas复制到新进程的vmas中. dup_mm function (kernel/fork.c)创建新mm并执行实际复制.没有直接调用copy_page_range,但我认为,static function dup_mmap可以内联到dup_mm并且它调用了copy_page_range.

在dup_mmap中,锁定了几个锁,包括新mm和旧oldmm：

356 down_write(&oldmm->mmap_sem);

在获取mmap_sem读取器/写入器信号量之后,在所有mmaps上都有一个循环来复制它们的元信息：

381 for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm_next)

只有在循环之后(在你的情况下很长),mmap_sem才会被解锁：

465 out:

468 up_write(&oldmm->mmap_sem);

虽然rwlock mmap_sep被写入程序关闭,但没有任何其他读者或编写者可以使用oldmm中的mmaps做任何事情.

one thread cannot get cpu time until fork finish

So my question is one cpu was busy on fork,why the scheduler don’t migrate the process waiting on this cpu to other idle cpu?

您确定,其他线程已准备好运行且不想对mmaps执行任何操作,例如：

>捣乱新事物或取消不需要的东西,

>增加或缩小其堆(brk),

>增加其堆栈,

> pagefaulting

>或许多其他活动……？

Actually,the wait-cpu thread is my IO thread,which send/receive package from client,in my observation,the package always exist,but the IO thread cannot receive it.

你应该检查你的wait-cpu线程的堆栈(甚至还有SysRq),以及那种I / O. mmaping文件是I / O的变体,它将被fork阻塞在mmap_sem上.

您还可以检查wait-cpu线程的“上次使用的cpu”,例如在顶部监视实用程序中,通过启用线程视图(H键)并添加“上次使用的cpu”列来输出(fj在较旧; f滚动到P,输入较新).我认为你的wait-cpu线程可能已经在另一个cpu上,只是不允许(未准备好)运行.

如果你只使用fork来创建exec,那么它对以下内容很有用：

>切换到vfork exec(或只是切换到posix_spawn). vfork will suspend您的进程(但是may not suspend your other threads,it is dangerous)直到新进程执行exec或退出,但执行可能比等待65 GB的mmaps被复制更快.

>或者不使用多个活动线程和多GB虚拟内存从多线程进程执行fork.您可以创建小型(没有多GB mmaped)帮助程序进程,使用ipc或套接字或管道与它通信,并要求它进行分叉并执行您想要的任何操作.