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/
