On 2016-09-21 16:19, Jonathan Bober wrote:
I moved discussion to sage-devel, but wanted to add for anyone who comes
across this and has problems: my simple temporary workaround is to
change the line
paristack_setsize(size, mem.virtual_memory_limit() // 4)
to
paristack_setsize(size,
I moved discussion to sage-devel, but wanted to add for anyone who comes
across this and has problems: my simple temporary workaround is to change
the line
paristack_setsize(size, mem.virtual_memory_limit() // 4)
to
paristack_setsize(size, min(mem.virtual_memory_limit() // 4, 10))
in
On 2016-09-20 12:54, Jonathan Bober wrote:
From reading what you've sent, I guess that what you have in mind is
calling mmap with PROT_NONE and then calling mprotect() to change that
to read/write whenever growing the stack? That seems like it might be a
reasonable thing to do (though I'm only
>From reading what you've sent, I guess that what you have in mind is
calling mmap with PROT_NONE and then calling mprotect() to change that to
read/write whenever growing the stack? That seems like it might be a
reasonable thing to do (though I'm only basing that on spending a few
minutes reading
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
Le 30/08/2016 à 19:06, William Stein a écrit :
> On Tue, Aug 30, 2016 at 9:56 AM, Thierry Dumont
> wrote:
>> I have two computers, and sage installed on both:
>>
>> 1) Ubuntu 12.04 , sage-7.3 on an nfs mount,y
>>
>> 2) Ubuntu 16.04, sage-7.3 on a local system, on a
On Tue, Aug 30, 2016 at 9:56 AM, Thierry Dumont
wrote:
> I have two computers, and sage installed on both:
>
> 1) Ubuntu 12.04 , sage-7.3 on an nfs mount,y
>
> 2) Ubuntu 16.04, sage-7.3 on a local system, on a ssd.
>
> With the first one, sage starts slowly (as could