On Monday, 28 March 2016 09:54:34 UTC-6, Nils Bruin wrote: > > On Monday, March 28, 2016 at 12:35:41 AM UTC-7, Volker Braun wrote: >> >> Presumably this is due to #19883 >> >> There isn't really any problem here, though. If you implement your own >> version of malloc then, in some implementations, you'll need about as much >> virtual memory as ram to do the accounting. It just uses your 128TB of >> virtual memory space. >> >> On a related note, 'ulimit -v" is not a good way to restrict memory usage. >> > > It's a simple one to set, though, and in many contexts it protects > against silly memory errors (e.g., on a multi-user machine, it helps to > kill runaway processes before their memory usage causes excessive > thrashing). So I think in practice you'll often meet such limits. Perhaps > we should take any ulimits into account when we compute our defaults? With > #19883, 1/4 of the virtual address space is allocated for the pari stack. > Perhaps we should take the ulimit into account when computing this max size? >
I didn't try fiddling with ulimits recently, but as I recall -v was the only one related to memory that actually worked, that's the reason I was using it for SageNB and SageMathCell... On a related note Python's default recursion limit seems to be about 1000 independent of machine - those who don't like it can change to their particular huge memory situation. I think it is more sensible - a lot of memory is there usually not for the usage of a single process, but rather to allow running a lot of stuff at once. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
