Avi Kivity <[email protected]> writes:
> [email protected] wrote:
>>
>> I almost removed the tasklist_lock from all read paths. But as it
>> happens sending a signal to a process group is an atomic operation
>> with respect to fork so that path has to take the lock, or else
>> we get places where "kill -9 -pgrp" fails to kill every process in
>> the process group. Which is even worse.
>>
>
> Can't that be fixed by adding a per-pgrp lock, and having both fork()/clone()
> and kill(-pgrp) take that lock?
Possibly. The core issue though is that you still need to take a lock and
a big group can be as bad as just about anything else. So all you do with
a per group lock is you change the odds of hitting the problem and make the
code a little more complicated. For the small systems that most people have
I don't believe the tasklist_lock shows up at all.
If someone can find a data structure that I could use on two independent
machines to create processes in the same process group and still allow atomic
kill behavior between those two machines I think we would have something that
could be made to scale very well.
Until the point where I see the truly better data structure or that people
who can actually see problems with the lock start to fix it. I think
it is not to modify the data structure more than necessary, at runtime.
Modifying the global task list in the middle of readdir looks like it will
allow user space simply by running top with a fast update frequency to
cause problems for people on bigger machines. Which is really the
wrong direction to go.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
