DragonFly BSD
DragonFly kernel List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: phk malloc, was (Re: ptmalloc2)


To: Gary Thorpe <gathorpe79@xxxxxxxxx>
From: David Xu <davidxu@xxxxxxxxxxxxxx>
Date: Fri, 25 Feb 2005 16:00:51 +0800

8$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <421eae9d$0$718$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 61
NNTP-Posting-Host: 221.12.27.25
X-Trace: 1109318483 crater_reader.dragonflybsd.org 718 221.12.27.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:7840



Gary Thorpe wrote:
> David Xu wrote:
> 
>>
>>
>> Dan Melomedman wrote:
>>
>>> Bill Hacker wrote:
>>>
>>>> If the 'email proxy in question' is that fragile - your statement 
>>>> would appear to be true.
>>>
>>>
>>>
>>>
>>> It's only fragile because the OS doesn't guarantee preallocated memory.
>>> That's all. Anyway, I've made the decision to only run software like
>>> this on Linux. Linux actually has the system-wide overcommit switch 
>>> through
>>> 'sysctl'. I wish I could switch it on and off per process through an
>>> environment variable instead. Oh well, can't have it all.
> 
> 
> BSD/UNIX does not guarantee it's loans. Preallocating resources is 
> supposed to guarantee or at least improve reliability, but in this case 
> it doesn't.
> 
>>
>>
>> You will have an unusable machine if you turn on overcommit,
>> when memory is about to be exhausted, any code not written by you
>> will crash because they don't check if malloc will fail!
>> Any program and system utilities will core dump or be locked there
>> if memory is exhausted, in the machine, your code only occupies
>> 1/10000 or less, making 1/10000 code to be overcommit aware does not
>> make sense.
>>
>> Regards,
>> David Xu
> 
> 
> Look: the point about reliability is that user-land software CANNOT 
> detect overcommit. They do a call to malloc() and it returns NON-NULL. 
> Later, they try to use the memory they allocated and get killed (along 
> with any other unfortunate processes that happen to cause page faults) 
> when the system runs out of memory. How do you write reliable programs 
> in this case?

If you want a reliable environment, spends more money on it, buy more
memory, and only run one service on it, and set a maximum connection
limits etcs. I don't think you can do 100$ work and only spends 1$.
even if you write your code in overcommit aware, whenever you link other
libraries which are not designed in overcommit way, your overcommit code 
is useless, unless you write all world source code in overcommit aware,
then you get you want, but that is impossible, so face it, this is how 
life works, life is not perfect.

David Xu




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]