Re: [lc-devel] About 2.4.21 stability

[Rodrigo S. de C. <rc...@im...>]

Hey Ero,

On Mon, Oct 13, 2003 at 11:24:03PM +0300, Ero Carrera wrote:
> I've notice that some words have been said on stability of the cc path
> on 2.4.21. I have to say that I've been running cc on 2.4.21 in
> production use for months now with no complaints on its stability.

Thanks for you feedback! :-)

> I ported/fixed myself the patch for 2.4.19 (fixed it just so that
> issuing a patch cmd won't give any errors). That version did however
> have some 'fun' with the overcommit feature of the kernel. If a
> hungry process allocated more memory than the system could really
> provide, the whole box went down in a swap storm whenever the kernel
> figured out that it could actually not really satisfy one the memory
> writes to pages allocated but not reserved for the process (after
> all, that's the idea of overcommit).

Great to know that. That's the sort of error I first think it's caused
by CC before trying to test the stock kernel. Any news about this
problem in 2.4.22?

> One "solution" (rather, a low quality fix) was to limit the maximum
> memory per process to (in my case) 196MiB (I have more than that
> physically), with the hope that if a single process wants more than
> that, the kernel won't allocate more.  The problem would still exist
> if several applications would, simultaneously, start behaving like
> that. But is something that has just happened once under extreme
> machine load and could have been prevented with lower memory limits.
>
> I suppose, cc and overcommit don't exactly get along well, because a
> cc 'enabled' kernel will (probably) think that always has memory to
> give away (because of the compression). But this you'll know better
> than me.

We don't change how many pages the system has (in kernel point of
view), therefore it shouldn't be a problem. But that's a very simple
analysis, I am not too aware of overcommit feature.

> To fix the swap storm crashes the maximum process memory setting I
> changed was on the file "include/asm/resource.h", namely the member
> RLIMIT_AS to have a definite value, instead of RLIM_INFINITY.
> 
> I hope this info is of some use to somebody.

It's very useful, mainly when testing CC stability. Thanks.

Regards,
-- 
Rodrigo