This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: Richard dot Earnshaw at arm dot com, geoffk at geoffk dot org, jsm28 at cam dot ac dot uk
- Cc: gcc-patches at gcc dot gnu dot org, zack at codesourcery dot com
- Date: Sat, 15 Feb 2003 14:28:32 -0500 (EST)
- Subject: Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
- References: <Pine.LNX.4.33.0302151905150.18402-100000@kern.srcf.societies.cam.ac.uk>
> From: "Joseph S. Myers" <jsm28@cam.ac.uk>
>
> On Sat, 15 Feb 2003, Richard Earnshaw wrote:
>
> > > It doesn't make sense for us to try to consider RLIMIT_DATA etc, since
> > > we don't have enough control to guarantee that we don't go over those.
> > >
> >
> > RLIMIT_DATA would be completely wrong anyway. That's the maximum virtual
> > data size (including swapped out data). If the compiler exceeds that then
> > it's just going to get killed by the OS.
>
> But you shouldn't treat the rlimits as saying you should use up to that
> amount of memory anyway; you should take a *fraction* of the smallest
> rlimit (just as you take a fraction of the physical memory). They are
> likely to be set as sanity checks to prevent one user killing the machine
> for others by accident, not to indicate that using up to the rlimit
> routinely is sensible.
That's exactly what I meant. Whether that fraction is the same 1/8
that we use for RAM is yet to be determined. All of this is moot
unless I can get Richard and Geoff to agree on the implementation
details.
Guys, do we want the patch or not?
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu