lkml.org 
[lkml]   [2000]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Virtual vs. physical swap & shared memory forks (clone)
    > >       For your system, since you aren't running mission critical stuff, you
    > >can choose to allocate 1G of Vmem, and implement 'killing' on the above
    > >formula. But the *simple* behavior should be the most predictable -- that
    > >of "no mem" resulting in ENOMEM on calls asking for memory.
    >
    > Why bother, when there is a definate disadvantage go doing so, and your
    > process can run OOM without getting ENOMEM anyway?
    ---
    The idea is *predictability*. Guarantees of behavior. Your user
    deamon is fine for many cases, but it's execution is not deterministic.
    What's in the config files may or may not represent what is in memory (assuming
    it can be sent a HUP to reread). It may be paged out to disk or even in
    memory -- may get insufficient priority if real-time processes have priority.

    If I'm running as an end user -- you would expect me to go read
    the memory priority policy of the 'hour' to know how my programs will behave?
    That's not acceptable -- and it is even questionable whether or not on a
    secure system you'd want to make that information readable by all. On
    a timeshare system at UCSB, it can make sense to have some sludge'n'fudge
    on how this topic is handled. On a secure/mission critical system you need
    the ability to have high integrity, easily predictable systems. Complexity
    while perhaps proportional to usefulness is inversely proportional to
    integrity.

    You do the user-space demon -- it's a great idea. But let's also
    agree to implement the vswap idea to allow overcommit or not. That way
    you can have the behavior you want, and I can have the behavior I *need*
    and we can both have a 'win-win' situation....? No? Just like for the 2.3
    series you have to add a 'shm' entry to continue to use shared memory, in
    2.5 somewhere, you can just add a 'vswap' entry to continue to do overcommit.

    -l


    --
    Linda A Walsh | Trust Technology, Core Linux, SGI
    law@sgi.com | Voice: (650) 933-5338

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

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:2.760 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site