Greetings!
Santiago Vila writes:
> On Sun, 2 Oct 2016, Camm Maguire wrote:
>
>> Greetings! I just wanted to keep you abreast of the latest upload.
>> I've put in an improvement which I hope will allow better use of the
>> ram available without running into the fork/exec faults
On Sun, 2 Oct 2016, Camm Maguire wrote:
> Greetings! I just wanted to keep you abreast of the latest upload.
> I've put in an improvement which I hope will allow better use of the
> ram available without running into the fork/exec faults we had seen in
> some configurations. This does not
Greetings! I just wanted to keep you abreast of the latest upload.
I've put in an improvement which I hope will allow better use of the
ram available without running into the fork/exec faults we had seen in
some configurations. This does not address the question of 'how much
memory should we
re memory II have,
> the more memory they take, so I still have the problem that I can't
> measure how much memory they really need.
>
> Thanks.
> From unknown Mon Sep 26 19:22:45 2016
> X-Loop: ow...@bugs.debian.org
> Subject: Bug#827953: maxima: Uses too much memory to
Hello Camm.
Nice to hear from you again.
On Tue, 13 Sep 2016, Camm Maguire wrote:
> It appears that all is working as intended, that gc is triggered and
> keeping the active heap to about 2.8Gb (or 3.9Gb with relocatable copy
> area) of a detected max of 5.3Gb (see core pages, and physical
Greetings, and thanks so much!
It appears that all is working as intended, that gc is triggered and
keeping the active heap to about 2.8Gb (or 3.9Gb with relocatable copy
area) of a detected max of 5.3Gb (see core pages, and physical memory).
At the end of this experiment, the rss of this process
On Mon, 25 Jul 2016, Camm Maguire wrote:
> If this is happening, then it is indeed a bug. The intent is to use
> physical ram only by default unless the application itself insists on
> more. Going into swap by default obviously defeats the performance goal
> of expanding the memory anyway. You
Greetings, and thanks for your report!
Santiago Vila writes:
> On Sun, 10 Jul 2016, Camm Maguire wrote:
>
>> Greetings, and thanks so much for your report! More reply later, but
>> just want to point out for now that the memory used for the build
>> depends on the memory
On Sun, 10 Jul 2016, Camm Maguire wrote:
> Greetings, and thanks so much for your report! More reply later, but
> just want to point out for now that the memory used for the build
> depends on the memory available at runtime. These packages will build
> just fine on machines with small
Greetings, and thanks so much for your report! More reply later, but
just want to point out for now that the memory used for the build
depends on the memory available at runtime. These packages will build
just fine on machines with small memories. The memory usage algorithm
is a performance
Package: maxima
Version: 5.38.0-3
Hello Camm.
The more memory it has the machine on which I build this package,
the more memory it uses during the build, and there does not seem to
be a limit for that.
Last time it was a machine with 8GB RAM. The file /proc/meminfo
reported a Committed_AS
11 matches
Mail list logo