<div dir="ltr">in my test, it has a chance to get the output from the child first using the taskset command. otherwise, the child and the parent are always on different cores in which case i think the parent is running and the child is on the rbtree of runqueue of other core just after fork at the most moment<br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div dir="ltr"><br>
</div><div class="wps_signature" dir="auto"></div><div class="wps_quotion">在 valdis.kletnieks@vt.edu，2017年12月9日 16:20写道：<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p/><p dir="ltr">On Sat, 09 Dec <a href="tel:201711">2017 11</a>:04:09 +0330, alireza sanaee said: <br>
<br>
> I think if it works in that way, it doesn't make sense at all!!!! Parent <br>
> and child ordering rules should preserve even on different cores! <br>
<br>
Find where in kernel/sched.c there's specific code to guarantee that <br>
if the child/parent is started on one core, the other isn't scheduled again <br>
until after the first one runs, rather than run immediately because it's <br>
able to run on an otherwise idle core, so you don't get a 'first' or <br>
'last', but 'at the same time'. <br>
<br>
And if they run concurrently, the printf output will have a race <br>
condition. At that point, the order of output is probably determined <br>
by something other than which one scheduled first (the I/O stack <br>
or exit() processing being the primary suspects). <br>
</p>
</blockquote></div>