#13880: Respect ulimit -v for GAP memory pool size
--------------------------------+-------------------------------------------
Reporter: vbraun | Owner: jason
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-5.6
Component: misc | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Volker Braun | Merged in:
Dependencies: | Stopgaps:
--------------------------------+-------------------------------------------
Comment (by jdemeyer):
Replying to [comment:8 vbraun]:
> I'm sure you can improve on `available_ram()` but its good enough for
starting GAP, I think. The perfect is the enemy of the good.
But I'd say that this patch actually makes things worse than they are. GAP
currently works fine with `ulimit -v`, it automatically adjusts (remember
the "halving pool size" messages).
> For libGAP the pool is actually in the Sage process, so what Jeroen
suggests would be a bad idea.
No, because this ticket doesn't refer to libGAP.
> Also, I don't think the user's intention when setting `ulimit -v` was
for Sage to spawn a couple of processes that each try to get as close as
possible to the limit.
I don't think the user intends GAP to take 1/10th of the memory either. If
I would set the memory limit to 2GB and GAP doesn't want to allocate
300MB, I would be quite surprised.
I do agree this is all bikeshedding, that's why I intentionally don't set
this to needs_work.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13880#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
