On 08/21/2013 06:23 PM, Dave Hansen wrote:
> On 08/21/2013 08:22 AM, Jerome Marchand wrote:
Instead of introducing yet another tunable, why don't we just make the
ratio that comes in from the user more fine-grained?
sysctl overcommit_ratio=0.2
We change the internal
On 08/21/2013 08:22 AM, Jerome Marchand wrote:
>> > Instead of introducing yet another tunable, why don't we just make the
>> > ratio that comes in from the user more fine-grained?
>> >
>> >sysctl overcommit_ratio=0.2
>> >
>> > We change the internal 'sysctl_overcommit_ratio' to store tenths
On 08/19/2013 06:55 PM, Dave Hansen wrote:
> On 08/19/2013 08:17 AM, Jerome Marchand wrote:
>> Some applications that run on HPC clusters are designed around the
>> availability of RAM and the overcommit ratio is fine tuned to get the
>> maximum usage of memory without swapping. With growing memory
On 08/19/2013 06:55 PM, Dave Hansen wrote:
> On 08/19/2013 08:17 AM, Jerome Marchand wrote:
>> Some applications that run on HPC clusters are designed around the
>> availability of RAM and the overcommit ratio is fine tuned to get the
>> maximum usage of memory without swapping. With growing memory
On 08/19/2013 08:17 AM, Jerome Marchand wrote:
> Some applications that run on HPC clusters are designed around the
> availability of RAM and the overcommit ratio is fine tuned to get the
> maximum usage of memory without swapping. With growing memory, the
> 1%-of-all-RAM grain provided by overcomm
Some applications that run on HPC clusters are designed around the
availability of RAM and the overcommit ratio is fine tuned to get the
maximum usage of memory without swapping. With growing memory, the
1%-of-all-RAM grain provided by overcommit_ratio has become too coarse
for these workload (on a
6 matches
Mail list logo
