On Tue, 5 Jun 2007, David Rientjes wrote:
> If that fails, we can't allocate elsewhere because then we have taken
> exclusive memory from other applications and is contrary to the definition
> of mem_exclusive. You need to construct your cpuset hierarchy with these
> scenarios in mind; when you ask for an exclusive cpuset, it shouldn't come
> with a disclaimer that says "if another cpuset that is also exclusive
> happens to OOM, we'll steal your memory anyway and it's not our problem if
> the dying task gets stuck in D state and doesn't exit synchronously or
> reliably because all we did was send it a SIGKILL."
Exclusive is not as absolute as you may think. There is also the
GFP_KERNEL exception.
Processes stuck in D state is another issue with reliability.
> > So its seems that the patch is addressing an imagined situation?
> No, it's returning us to the previous logic where an exclusive cpuset was
> actually exclusive.
>
> And, again, without this change it is possible to allocate in other
> exclusive cpusets without first exhausting your own memory reserves.
> That's wrong.
That is already occurring with GFP_KERNEL. So your patch really does not
have the purifying effect on exclusivity that you expect. This looks all
more like hunting for elusive idealistic cpuset behavior to me.
-
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]
