After spending some time reading on the subject, I think I might have a
solution to this "problem". It involves calling mmap() with PROT_NONE,
which will require a patch to upstream PARI.
However, before implementing this, I would like a *strong commitment*
from somebody to review my patch whe
On 2016-09-19 19:58, Jeroen Demeyer wrote:
* https://lwn.net/Articles/627557/
This last page indicates that one should use PROT_NONE to work around
the issue you are having.
Note this nice quote:
> Sadly, the commit charge implications of MAP_NORESERVE are documented
but silently broken, b
On 2016-09-19 14:04, Jonathan Bober wrote:
With overcommit_memory set to 2, I'm not sure that there is a right
thing to do. If I'm the only person in the world with this problem, then
I should keep my mouth shut and get with the times, but I don't think
this setup is so unreasonable.
Some point
On 2016-09-19 19:01, William Stein wrote:
We should revert whatever trac ticket did this
The first version of this is from
https://trac.sagemath.org/ticket/19883
or at least make it an option to not allocate such a large address space.
That's easy to do. How would you see the user interface
On 2016-09-19 14:04, Jonathan Bober wrote:
That doesn't really solve the problem, which I phrased poorly. The
machine has an (antiquated) setup where, when a process requests X bytes
of memory, the kernel reserves X bytes of physical memory for it.
Well, in that case you would indeed "lose" 1/4
>
>
> Anyway, where exactly is this allocation coming from? Is it a default PARI
> setting, or does it come from the way that Sage uses PARI? (I mean, to whom
> should I address my "hate mail"? :)
>
I think it is a problem in the way that Sage uses PARI. I just tried "sage
-sh" with sage-7.3, the
On Monday, September 19, 2016 at 6:02:22 AM UTC-7, Paul Leopardi wrote:
>
> Hello,
> I am trying to use global variables to control the behaviour of Python
> functions called from Sage. (Yes, I know there is probably a better way to
> do it, but I am still interested in what's going on here.)
>
>
Hello,
I am trying to use global variables to control the behaviour of Python
functions called from Sage. (Yes, I know there is probably a better way to
do it, but I am still interested in what's going on here.)
If in foo.py I have
def bar():
print blah
def baz():
global zilch
zilc
On Mon, Sep 19, 2016 at 12:13 PM, Jeroen Demeyer
wrote:
> On 2016-09-19 13:02, Jonathan Bober wrote:
>
>> If I ulimit -v 8 GB, say, (which is 512/64), and the PARI allocater
>> immediately grabs 2 GB of the virtual address space for itself, then
>> that seems like it leaves only 6 GB for malloc/s
On 2016-09-19 13:02, Jonathan Bober wrote:
If I ulimit -v 8 GB, say, (which is 512/64), and the PARI allocater
immediately grabs 2 GB of the virtual address space for itself, then
that seems like it leaves only 6 GB for malloc/sage_malloc/whatever
else, which would be effectively limiting the phy
On Mon, Sep 19, 2016 at 11:04 AM, Jeroen Demeyer
wrote:
> On 2016-09-19 11:54, Jonathan Bober wrote:
>
>> But in that case the memory does effectively get "used", if it is the
>> case that a quarter of the machine's memory is only available from the
>> PARI memory allocater. If I'm not using the
On 2016-09-19 11:54, Jonathan Bober wrote:
But in that case the memory does effectively get "used", if it is the
case that a quarter of the machine's memory is only available from the
PARI memory allocater. If I'm not using the PARI parts of Sage, is that
memory completely wasted?
There should
On Mon, Sep 19, 2016 at 8:29 AM, Jeroen Demeyer
wrote:
> Why don't you use ulimit -v to limit the per-process available memory?
> That would make sense when starting lots of processes even without the PARI
> non-issue.
Because I was being stupid. That seems like it should work ok.
But in that
On Sun, 18 Sep 2016, jack wrote:
Ubuntu16.04.
P=plot(log((1+x)/(1-x)), (x, -1,1))
show(P)
gives a lengthy error message which ends with
ImportError: cannot import name scimath
I installed sage at /home/jack/Tools
One clue might be the initial message I get on initiating sage in a
terminal.
Why don't you use ulimit -v to limit the per-process available memory?
That would make sense when starting lots of processes even without the
PARI non-issue.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and st
15 matches
Mail list logo
