On Tue, 7 Feb 2006, Andi Kleen wrote:
> On Tuesday 07 February 2006 02:55, Christoph Lameter wrote:
> > I just tried to oom a process that has restricted its mem allocation to
> > node 0 using a memory policy. Instead of an OOM the system began to swap
> > on node zero. The swapping is restricted to the zones passed to
> > __alloc_pages. It was thus swapping node zero alone.
>
> Thanks for doing that work. It's needed imho and was on my todo list.
This is talking not about the text above but about what comes later right?
The OOM behavior for a constrained allocation with no swap?
> > + gfp_t gfp_flags; /* flags ORed into gfp_flags for each allocation */
>
> I don't think it's a good idea to add it to the struct mempolicy. I've tried to
> make it as memory efficient as possibile and it would be a waste to add such
> a mostly unused field. Better to pass that information around in some other way.
Memory policies are rare and this would be insignificant on any NUMA
system.
> (in the worst case it could be a upper bit in policy, but I would prefer
> function arguments I think)
An upper bit in policy would require special processing in hot code paths.
The current implementation can simply OR in a value that is in a cacheline
already in the data cache.
I'd rather keep it separate.
Function arguments? Add function pointer to mempolicy for allocation?
Then there is the other issue:
Should the system swap if an MPOL_BIND request does not find enough
memory? Maybe it would be good to not swap, rely on zone_reclaim only and
fail if there is no local memory?
We could change __GFP_NO_OOM_KILLER to __GFP_CONSTRAINED_ALLOC and then
not invoke kswapd and neither the OOM killer on a constrained allocation.
-
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]
