[lkml]   [2005]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: User space out of memory approach
    On Tue, 2005-01-11 at 04:03 +0200, Edjard Souza Mota wrote:
    > > 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:

    I consider the invocation of out_of_memory in the first place. This is
    the real root of the problems. The ranking is a different playground.
    Your solution does not solve
    - invocation madness
    - reentrancy protection
    - the ugly mess of timers, counters... in out_of_memory, which aren't
    neccecary at all

    This must be solved first in a proper way, before we talk about ranking.

    You are definitely curing the symptom instead of the cause.

    > 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.

    What is the default behaviour when no userspace settings are available -
    Nothing ? Are you really expecting that we change every root fs in order
    to be able to upgrade the kernel for solving this _kernel_ problem ?

    Who is setting up those userspace constraints ? Joe User, who is barely
    able to find the power on button on his box ? The sysadmin, who will
    have to adjust the list for each box depending on the apps it runs or
    the user who is logged into the box ?

    Memory management _is_ a kernel task and so the shortage of memory has
    to be handled by the kernel on its own in the first place. Adding user
    space support for certain tasks is a good thing, but not a solution to
    the problem itself.

    > 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.

    I know the constrains of embedded boxes well enough to know that there
    is a bit of a difference to a desktop machine.

    > 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.

    I'm running Andrea's and my combined fixes on a couple of embedded and
    desktop boxes and it has proven to be a proper in kernel solution for
    the in kernel problem.

    I don't argue againts the ability to provide a culprit list to the
    kernel, but as I said before it only can be a optional addon to a proper
    in kernel solution.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.026 / U:21.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site