On Sun, 2012-05-06 at 20:37 +0300, Lauri Kasanen wrote: > > > This drops Monkey's RAM use from 56.6mb to 4.2mb.
This is ambiguous, how exactly did you measure memory? We're interested specifically in the RSS. When we talk about virtual address space it comes pretty cheap as it doesn't touch/dirty unused physical frames. In any case a normal working set for monkey will be quite small (~5mb). > > > > > > > Why do you assume that the process is using 56.6MB ?, no matters how > > bigger the stack is.. the kernel will not waste memory pages if they > > are not required... > > Yes, they aren't used, but they do consume the virtual address space, which > is limited on 32bit platforms (2gb default, IIRC). > > I thought it'd make sense to save on that too, given the embedded focus ;) The working set size of monkey is tiny, even refrigerators can afford it, no need to worry about memory usage. > > > > > > > Linux defaults to 8mb stacks (one per thread), and we can quite > > > comfortably drop 7.5mb off each of them. Note that this RAM is not > > > measured by valgrind (it measures heap only), you can count it with "pmap > > > -d PID". > > > > I think that we do not need to play with the stack size in the source > > code, because most of this is up to the OS setup, otherwise we will > > need to cover all specific scenarios, i would suggest just leave it as > > it works now because the stack size can be adjusted from the parent > > process through 'ulimit' user space program. Agreed, users can always set it with ulimit/prlimit, we shouldn't hardlimit limit the size ourselves, that takes away functionality and flexibility. - Davidlohr _______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
