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
|
