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 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
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
I just ran into this problem on a machine with 512 GB of ram, where the
Sage virtual memory usage is around 128 GB. Volker might consider that a
tiny fraction of the possible address space, but it still seems a bit
ridiculous. I noticed this when I tried to use @parallel to 64 processes.
(overcommi
On 2016-08-31 08:57, Thierry Dumont wrote:
On machine 2, sage stating process (as mesured with top) uses about 39GB
(no more...) out of 153.79 available.
It doesn't actually "use" that memory. It is reserved virtual memory but
it does not take up physical memory or swap space.
--
You receive
Le 31/08/2016 à 00:19, Volker Braun a écrit :
> On Tuesday, August 30, 2016 at 11:03:39 PM UTC+2, leif wrote:
>
> 48 GB claimed by *every* Sage process here
>
>
> Its a tiny fraction of the 128TB address space. We are not talking about
> used RAM here.
>
> which is *total* (not free!) p
On 2016-08-30 20:26, leif wrote:
this makes the usage of 'ulimit -v' nearly impossible
I don't see why. You can still use 'ulimit -v'.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails fr
On Tuesday, August 30, 2016 at 11:03:39 PM UTC+2, leif wrote:
>
> 48 GB claimed by *every* Sage process here
Its a tiny fraction of the 128TB address space. We are not talking about
used RAM here.
which is *total* (not free!) physical RAM + total (not free) swap space,
> in bytes.
>
Really,
On Tue, Aug 30, 2016 at 2:02 PM, Nils Bruin wrote:
> On Tuesday, August 30, 2016 at 1:23:47 PM UTC-7, Volker Braun wrote:
>>
>>
>> ulimit -v is useless anyways
>
>
> In my experience it is quite useful on multi-user machines to limit the
> effects of runaway computer algebra processes. Many packag
leif wrote:
> William Stein wrote:
>> 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, sag
On Tuesday, August 30, 2016 at 1:23:47 PM UTC-7, Volker Braun wrote:
>
>
> ulimit -v is useless anyways
>
In my experience it is quite useful on multi-user machines to limit the
effects of runaway computer algebra processes. Many packages (maple, magma
at least) will segfault earlier with a ulim
On Tuesday, August 30, 2016 at 8:26:29 PM UTC+2, leif wrote:
>
> IMHO horrible (as *each* Sage subprocess is claiming that amount of
> memory, here usually ~28 to 50+ GB IIRC, as it depends on the physical
> memory installed) and dangerous, as this makes the usage of 'ulimit -v'
> nearly impossi
William Stein wrote:
> 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 cou
21 matches
Mail list logo
