On Fri, Dec 17, 2010 at 3:03 AM, Ketil Malde ke...@malde.org wrote:
So I still think the 80% rule is pretty good - it's simple, and
although it isn't optimal in all cases, it's conservative in that any
larger bound is almost certainly going to thrash.
Did you get a chance to test the 80%
You might like to read about free and reclaimable memory on Linux
systems. I recommend that you go
http://linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html
and run the C programs that are included in the article. Another good
way to learn about Linux memory is to Google with the
On Fri, Dec 17, 2010 at 3:03 AM, Ketil Malde ke...@malde.org wrote:
So I still think the 80% rule is pretty good - it's simple, and
although it isn't optimal in all cases, it's conservative in that any
larger bound is almost certainly going to thrash.
Please test the 80% rule, and report the
On Thu, Dec 16, 2010 at 4:13 AM, Simon Marlow marlo...@gmail.com wrote:
If your program has large memory requirements, you might also benefit from
parallel GC in the old generation: +RTS -N2 -qg1.l
Testing shows this advice did not help in my case. The program that
implements the undecidable
John D. Ramsdell ramsde...@gmail.com writes:
In absence of any explicit limits, I think a sensible default is to set
maximum total memory use to something like 80%-90% of physical RAM.
This would be a poor choice on Linux systems. As I've argued
previously in this thread, the best choice is
On 16/12/2010 00:37, John D. Ramsdell wrote:
On Wed, Dec 15, 2010 at 7:59 AM, Simon Marlowmarlo...@gmail.com wrote:
The -M flag causes the GC algorithm to switch from copying (fast but
hungry) to compaction (slow but frugal) as the limit approaches.
Ah, so that's what it's doing. My
Simon Marlow marlo...@gmail.com writes:
ulimit is a good way to catch an infinite loop. But it's not a good
way to tell GHC how much memory you want to use - if GHC knows the
memory limit, then it can make much more intelligent decisions about
how to manage memory.
I'm interpreting this
On Thu, Dec 16, 2010 at 4:45 AM, Ketil Malde ke...@malde.org wrote:
In absence of any explicit limits, I think a sensible default is to set
maximum total memory use to something like 80%-90% of physical RAM.
This would be a poor choice on Linux systems. As I've argued
previously in this
On 13/12/2010 15:45, Peter Simons wrote:
Hi Mathieu,
Why don't you use ulimit for this job?
$ ulimit -m 32M; ./cpsa
yes, I was thinking the same thing. Relying exclusively on GHC's ability to
limit run-time memory consumption feels like an odd choice for this task.
It's nice that
Hi John,
I think the previous responder was asserting the 32M limit, not you.
I believe the previous poster suggested that you use ulimit to provide a
hard upper bound for run-time memory use. That 32M figure seemed to be made
up out of thin air just as an example to illustrate the syntax of
On Wed, Dec 15, 2010 at 7:59 AM, Simon Marlow marlo...@gmail.com wrote:
The -M flag causes the GC algorithm to switch from copying (fast but
hungry) to compaction (slow but frugal) as the limit approaches.
Ah, so that's what it's doing. My measurements say that part of the
code is working
Hi John,
On Mon, Dec 13, 2010 at 10:45 AM, Peter Simons sim...@cryp.to wrote:
Relying exclusively on GHC's ability to limit run-time memory
consumption feels like an odd choice for this task. It's nice that
this feature exists in GHC, but it's inherently non-portable and
outside of
Hi Peter
I beg your pardon? I didn't say anything about 32M. I said that
designing software to rely on a GHC-enforced memory limit as a means of
dealing with infinite loops feels really not like a particularly good
solution.
As I understand the discussion, it's not about infinite loops.
On Tue, Dec 14, 2010 at 1:48 PM, Peter Simons sim...@cryp.to wrote:
I beg your pardon? I didn't say anything about 32M. I said that
designing software to rely on a GHC-enforced memory limit as a means of
dealing with infinite loops feels really not like a particularly good
solution.
Sorry
Hi John,
Why don't you use ulimit for this job?
$ ulimit -m 32M; ./cpsa
Regards,
Mathieu
On Fri, Dec 10, 2010 at 12:51 PM, John D. Ramsdell ramsde...@gmail.com wrote:
Please excuse the grammar errors in my last post. I was very tired.
The name of the package that supplies the free
Hi Mathieu,
Why don't you use ulimit for this job?
$ ulimit -m 32M; ./cpsa
yes, I was thinking the same thing. Relying exclusively on GHC's ability to
limit run-time memory consumption feels like an odd choice for this task.
It's nice that this feature exists in GHC, but it's inherently
On Mon, Dec 13, 2010 at 10:17 AM, Mathieu Boespflug mb...@tweag.net wrote:
Hi John,
Why don't you use ulimit for this job?
By default, the GHC runtime will allocate memory beyond what it takes
for takes to cause thrashing on a Linux box. However, if you give the
GHC runtime a limit with the
On Mon, Dec 13, 2010 at 10:45 AM, Peter Simons sim...@cryp.to wrote:
Hi Mathieu,
... There really ought to be a better way to catch an infinite loop that this.
It all comes down to picking the correct memory limit. How do you
propose to do it? How did you come up with the number 32M? That
Please excuse the grammar errors in my last post. I was very tired.
The name of the package that supplies the free function on Linux is
procps, not procpc. It's hosted on SourceForge. To compile my
program, do the following:
$ mv memfree.txt memfree.l
$ make LDLIBS=-ll memfree
John
On Thu,
On 08/12/2010 16:34, Andrew Coppin wrote:
On 08/12/2010 03:29 PM, Brandon S Allbery KF8NH wrote:
Then build your CGIs restricted. Restricting the runtime by default,
*especially* when setting runtime options at compile time is so much of a
pain, is just going to cause problems. I'm already
On 09/12/2010 12:48 PM, Simon Marlow wrote:
On 08/12/2010 16:34, Andrew Coppin wrote:
It appears that with GHC 7, you can just say something like
|-with-rtsopts=-H128m -K1m| while compiling your program, and now that
will forever be the default RTS settings for your program.
Nice! I didn't
I found out how to compute a good memory limit for the GHC runtime on
Linux systems. One opens /proc/meminfo, and sums the free memory with
the reclaimable memory. The memory allocated to file buffers and the
disk cache are reclaimable, and can be added to the memory of a
growing GHC process.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/8/10 02:17 , Anders Kaseorg wrote:
On Sat, 2010-12-04 at 13:42 -0500, Brandon S Allbery KF8NH wrote:
We went over this some time back; the GHC runtime is wrong here, it
should only disable flags when running with geteuid() == 0.
No. +RTS
On 08/12/2010 03:29 PM, Brandon S Allbery KF8NH wrote:
Then build your CGIs restricted. Restricting the runtime by default,
*especially* when setting runtime options at compile time is so much of a
pain, is just going to cause problems. I'm already thinking that I may have
to skip ghc7.
With
On Wed, 8 Dec 2010, Brandon S Allbery KF8NH wrote:
Then build your CGIs restricted. Restricting the runtime by default,
*especially* when setting runtime options at compile time is so much of
a pain, is just going to cause problems. I'm already thinking that I
may have to skip ghc7.
One
On 11/29/2010 03:00 PM, John D. Ramsdell wrote:
only one other solution. Somehow the default behavior of the runtime
system must impose some reasonable limit. Here is the problem with
Shouldn't you configure your operating system to impose some reasonable
limit? That's not the job of the
On Sat, 2010-12-04 at 13:42 -0500, Brandon S Allbery KF8NH wrote:
We went over this some time back; the GHC runtime is wrong here, it
should only disable flags when running with geteuid() == 0.
No. +RTS flags on the command line, at least, need to stay disabled in
all cases, not just setuid
I forgot to say what performance I got out of the new version of the
compiler on my application. I turns out a standard benchmark ran ever
so slightly slower after being compiled by 7.0.1 as compared with
6.12.1. Nothing exciting to report here.
John
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/24/10 20:59 , John D. Ramsdell wrote:
Due to a security concern, GHC 7.0.1 disables all runtime flags unless
a new flag is provided during linking. Since limiting memory usage is
so important, many developers will modify their cabal files to
Excerpts from Brandon S Allbery KF8NH's message of Sat Dec 04 13:42:48 -0500
2010:
We went over this some time back; the GHC runtime is wrong here, it should
only disable flags when running with geteuid() == 0. Also, the current
mechanism for specifying runtime flags at compile time is
Edward Z. Yang ezy...@mit.edu wrote:
There are many setuid binaries to non-root users, so getuid() != geteuid()
would probably make more sense, though I'm not 100% it has all the correct
security properties.
Might as well throw in getegid() != getgid() for good measure.
Another issue with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/4/10 14:35 , Riad S. Wahby wrote:
Edward Z. Yang ezy...@mit.edu wrote:
There are many setuid binaries to non-root users, so getuid() != geteuid()
would probably make more sense, though I'm not 100% it has all the correct
security properties.
On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Do you have an alternative to suggest? After all, the previous situation
wasn't good either.
I suggest that we should be able to specify RTS options at
compile/link time, or as pragmas in the Main module.
--
On Tue, Nov 30, 2010 at 9:24 AM, Ryan Ingram ryani.s...@gmail.com wrote:
I suggest that we should be able to specify RTS options at
compile/link time, or as pragmas in the Main module.
So if I wrote a really good, stable Haskell program, and made it
available in binary form, people ten years
Quoth Ryan Ingram ryani.s...@gmail.com,
I suggest that we should be able to specify RTS options at
compile/link time, or as pragmas in the Main module.
It would be good for me in any case if I could specify the value of
an option at compile time, though I suppose you mean to specify which
2010/11/30 Ryan Ingram ryani.s...@gmail.com
On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Do you have an alternative to suggest? After all, the previous situation
wasn't good either.
I suggest that we should be able to specify RTS options at
On Tue, Nov 30, 2010 at 9:24 AM, Ryan Ingram ryani.s...@gmail.com wrote:
On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Do you have an alternative to suggest? After all, the previous situation
wasn't good either.
I suggest that we should be able to
| The irony of this situation is deep. CPSA is a program that analyzes
| cryptographic protocols in an effort to expose security flaws. To
| ensure that the program does not crash a user's machine, I have to use
| a linker option that may expose the user to some security problems.
Do you have
On Mon, Nov 29, 2010 at 3:36 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| The irony of this situation is deep. CPSA is a program that analyzes
| cryptographic protocols in an effort to expose security flaws. To
| ensure that the program does not crash a user's machine, I have to use
On 2010-11-25 01:59, John D. Ramsdell wrote:
The irony of this situation is deep. CPSA is a program that analyzes
cryptographic protocols in an effort to expose security flaws. To
ensure that the program does not crash a user's machine, I have to use
a linker option that may expose the user to
Hello John,
Arguably the correct thing to do is to use GHC's hooks for
programatically specifying runtime options; unfortunately, because
this has to run /before/ any Haskell code starts, it's a bit
unwieldly: essentially you'll need a C stub file that scribbles
the correct options into char
On Thu, Nov 25, 2010 at 6:07 AM, Nils Anders Danielsson
n...@cs.nott.ac.uk wrote:
Is CPSA intended to be run by untrusted users (for instance with the
setuid bit set)?
http://hackage.haskell.org/trac/ghc/ticket/3910
Edward Z. Yang ezy...@mit.edu writes:
Arguably the correct thing to do is to use GHC's hooks for
programatically specifying runtime options; unfortunately, because
this has to run /before/ any Haskell code starts, it's a bit
unwieldly
Maybe what's needed is a way to allow certain RTS options
A quick review of GHC 7.0.1 revealed two challenges for developers.
I downloaded the GHC 7.0.1 sources, configured for a home directory
install, and built and installed the compiler. Very close to the end,
my machine froze, perhaps due to memory exhaustion. In any event, a
reboot allowed me to
44 matches
Mail list logo
