lkml.org 
[lkml]   [2006]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: OOM behavior in constrained memory situations
    Date
    On Tuesday 07 February 2006 18:51, Christoph Lameter wrote:

    > > 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.
    >
    > Well the ability to set bits for policy controlled allocations may come in
    > handy if we want to support memory policy controlling some other aspect
    > for page allocation.

    Actually looking at it again "v" should be aligned to 4 bytes anyways, so
    there is a unused 2 byte hole that you can use for this.

    Still think the way of converting the policy is more elegant though.

    > > 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
    >
    > That would work for MPOL_BIND. How about MPOL_INTERLEAVE with a restricted
    > set of nodes? cpusets may cause any policy to have a restricted nodeset.

    MPOL_INTERLEAVE isn't strict, so it can never cause OOMs unless the complete
    system is out of memory. It just changes which node is tried first.

    >
    > > > 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.
    >
    > Hmm.... Maybe make this a separate post?

    Do you have enough new thoughts on it for one?

    > > > 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.
    >
    > zone_reclaim can be configured to write out dirty file cache pages during
    > reclaim. So this could be addressed.

    Would be good.

    -Andi
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-07 19:05    [W:0.021 / U:32.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site