Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Vlad Raz <onegulin@gm...> - 2006-01-18 17:33:42
Please, correct me if I'm wrong,
but it looks like the thread group migration didn't ever work for 1.9.1 ope=
on 2.6-based Linux kernel.
The changes in 2.6 broke the logic of add_thread_group() function
(cluster/ssi/vproc/dvp_move.c). I'd like to mention just few from
I've found trying to make it working:
1. The task list with init_task as a head doesn't include all the
tasks anymore, but only thread leaders. That means for_each_process(t)
loop as it's used in add_thread_group() function can't find all the
tasks to be migrated,
when add_thread_group() is called from setup_pid_move().
That results in EINVAL return code with "cannot find all shares"
kernel debug message.
2. task_struct has a pointer to group_info structure, and the instance
of this group_info data is shared between processes when they are
created by fork().
The group_info information is copied only on the first write (copy-on-write=
That means group_info is normally shared between all the processes in a tre=
started from a shell interpreter process, unless it's explicitly
written back with
That results in EINVAL return code on a migration request,
and "partially shared with process" kernel debug message
for a process and its parent (bash).
3. p->sysvsem.undo_list almost always is NULL for all the processes,
so add_thread_group() thinks that they all are partially shared with each o=
So, my questions are:
Should it be mentioned explicitly that thread group migration doesn't
work in 1.9.1 and, I believe, in 1.9.2pre?
Are there any plans to make in working in 2.x?