On Tuesday 07 February 2006 18:29, Christoph Lameter wrote:
> 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
It could be a problem on those 32bit NUMA systems with only 1GB of lowmem.
There are some workloads with lots of VMAs and it's in theory possible
some application wants to set a lot of policy for them.
I back then spent some time to make the data structure as small as possible
and I would hate to destroy it with such thoughtless changes.
>
> > (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?
I was more thinking:
when MPOL_BIND == node_online_map automatically revert to MPOL_PREFERED with empty mask.
Then on the allocation only set the gfp flag for MPOL_BIND
Ok there might be small trouble with node hotplug, but that could be probably
ignored for now.
> 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?
Not sure. I guess it depends. Maybe it needs a nodeswappiness sysctl.
>
> 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.
That could be a problem if one node is filled with dirty file cache pages,
no? There needs to be some action to free it. I had a few reports of this case.
It needs to make at least some effort to wait for these pages and push them out.
On the other hand I would like to have less swapping for MPOL_BIND by
default than the global VM does. I remember
driving the system in quite severe swap storms when doing early mempolicy
testing.
-Andi
-
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]
