lkml.org 
[lkml]   [2000]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Linux 2.2.15pre12
    Hi,

    On Fri, 3 Mar 2000 17:33:06 +0000 (GMT Standard Time), Paul Jakma
    <paul.jakma@compaq.com> said:

    > just wondering, could linux implement a 'hard' memory alloc policy? a la
    > solaris/Tru64/and probably many other unices.. ie when memory is
    > allocated to an app, it's /guaranteed/ to be there?

    It doesn't really help. You can implement it, sure, but only by
    returning an unconditional ENOMEM if there is any risk of going over
    budget.

    Your user space app uses all the memory it can and then gets ENOMEM on
    the next malloc. Fine.

    Then named does a malloc. It gets ENOMEM and dies, and the freed memory
    gets gobbled by your memory-hog application. Then inetd does a malloc.
    It gets ENOMEM and dies. Then sendmail. Then init.

    The gradual (then rapid) performance degradation you get with relaxed
    memory committing is, in many ways, *much* better than hard overcommit
    rules when it comes to protecting system daemons.

    --Stephen

    -
    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:56    [W:3.460 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site