<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:&#13;<br>
&#13;<br>
&gt; I think if it works in that way, it doesn't make sense at all!!!! Parent&#13;<br>
&gt; and child ordering rules should preserve even on different cores!&#13;<br>
&#13;<br>
Find where in kernel/sched.c there's specific code to guarantee that&#13;<br>
if the child/parent is started on one core, the other isn't scheduled again&#13;<br>
until after the first one runs, rather than run immediately because it's&#13;<br>
able to run on an otherwise idle core, so you don't get a 'first' or&#13;<br>
'last', but 'at the same time'.&#13;<br>
&#13;<br>
And if they run concurrently, the printf output will have a race&#13;<br>
condition.&nbsp; At that point, the order of output is probably determined&#13;<br>
by something other than which one scheduled first (the I/O stack&#13;<br>
or exit() processing being the primary suspects).&#13;<br>
</p>
</blockquote></div>