On Sat, Dec 9, 2017 at 11:42 PM, strongbox8 wrote:
> 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 r
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
On Sat, 09 Dec 2017 11:04:09 +0330, alireza sanaee said:
> I think if it works in that way, it doesn't make sense at all Parent
> and child ordering rules should preserve even on different cores!
Find where in kernel/sched.c there's specific code to guarantee that
if the child/parent is start
I think if it works in that way, it doesn't make sense at all Parent
and child ordering rules should preserve even on different cores!
On Fri, Dec 8, 2017 at 9:06 PM, Perr Zhang wrote:
>
> maybe you should run the program like this:
>
> taskset 1 ./your_test_app
>
>
> ___
maybe you should run the program like this:
taskset 1 ./your_test_app
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
maybe you should run the program like this:
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I've read the post before, and I've seen a lot of saying
"sched_child_runs_first just not a guarantee of anything". But still,
there should be a moment that child process ran first. From my
experiment, there was no single time that child process ran before
father process. Isn't it interesting ?
On
Hi,
On Fri, Dec 08, 2017 at 11:07:15AM +0800, Rock Lee wrote:
>Hi,
>
>I ran my test code but always got the father process run first, even
>after setting sched_child_runs_first. Could anyone give me a hint?
>Here is my test code.
>
>#include
>#include
>#include
>
>int main(void)
>{
>struct t
Hi,
I tried a test in that code without any gettimeofday, the result is
the same. BTW, I've tried on my raspberrpi 3 with kernel 4.13.
Moreover, I also tried several ubuntu 16.04. The result were always
father process ran first.
On Fri, Dec 8, 2017 at 1:53 PM, Mulyadi Santosa
wrote:
>
>
> On Fri,
Hi,
I know the vfork guarantees the children run first. I am just curious
why sched_child_runs_first doesn't work. If there is a chance that
child process run first, I would be more glade, since I guess that how
it works, works with probability. However I tried more the 30+ times,
the resul
If my understanding of what Linus says in the post referenced below
is correct, there's never a guarantee which process would run first,
parent or child.
http://yarchive.net/comp/linux/child-runs-first.html
vfork(), on the other hand, is said in the post to always run the
child process first. See
On Fri, Dec 8, 2017 at 10:07 AM, Rock Lee wrote:
> Hi,
>
> I ran my test code but always got the father process run first, even
> after setting sched_child_runs_first. Could anyone give me a hint?
> Here is my test code.
>
> #include
> #include
> #include
>
> int main(void)
> {
> struct ti
Hi,
I ran my test code but always got the father process run first, even
after setting sched_child_runs_first. Could anyone give me a hint?
Here is my test code.
#include
#include
#include
int main(void)
{
struct timeval tv;
struct timezone tz;
int err;
pid_t ret = fork();
13 matches
Mail list logo
