lkml.org 
[lkml]   [2005]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: User space out of memory approach
    Some points on Thomas comments,

    >
    > I have no objections against the userspace provided candidate list
    > option, but as long as the main sources of trouble
    >
    > - invocation
    > - reentrancy
    > - timed, counted, blah ugly protection
    > - selection problem
    >
    > are not fixed properly, we don't need to discuss the inclusion of a
    > userspace provided candidate list.

    Any solution that doesn't offer a proper approach to the above issues
    should not be discussed anyway. By allowing the ranking goes up to the
    user space is not meant only for user testing ranking, but to keep the
    OOM Killer kernel code simpler and clean. As a matter of fact, even
    protected.

    Consider the invocation for example. It comes in two phases with this proposal:
    1) ranking for the most likely culprits only starts when memory consumption
    gets close to the red zone (for example 98% or something like that).
    2) killing just gets the first candidate from the list and kills it.
    No need to calculate
    at kernel level.

    The selection problem is very dependent on the ranking algorithm. For PCs it
    may not be a trouble, but for emdedded devices? yes it is. The ranking at the
    kernel level uses only int type of integer. If you get the log file
    for the ranking
    in any embedded device you will notice that many processes end up with
    the same ranking point. Thus, there will never be the best choice in this way.

    By moving just the ranking to the user space fix this problem 'cause you may
    use float to order PIDs with different indexes. The good side effect is that we
    allow better ways of choosing the culprit by means of diffrent calculations to
    meet different patterns of memory consumtion.


    > Postpone this until the main problem is fixed. There is a proper
    > confirmed fix for this available. It was posted more than once.
    >
    > Merging a fix which helps only 0,001 % of the users to hide the mess
    > instead of fixing the real problem is a real interesting engineering
    > aproach.
    >
    > I don't deny, that after the source of trouble is fixed it is worth to
    > think about the merging of this addon to allow interested users to
    > define the culprits instead of relying on an always imperfect selection
    > algorithm.

    br

    Edjard
    --
    "In a world without fences ... who needs Gates?"
    -
    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: 2005-03-22 14:09    [W:0.025 / U:0.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site