Re: long uptime memory consumption

[Roland McGrath]

> It seems that gnumach consumes an increasing amount of memory.
> I don't have earlier stats, but I remember it using 9MB, and now
> it's 10.6MB.

Now is the time to write that code using host_zone_info so you can see what
kinds of kernel objects might be involved.

> But the real shockers are the filesystems, the root filesystem with
> 63.3MB RSS.  This is of course because a large number of threads (ps

That should not cause RSS to necessarily be high, since all those pages of
thread structures and stack memory aren't wired and shouldn't be accessed
more than needed.  It might just be that your RAM all happens to be in use
for cached disk pages because there is nothing better for it to do.

> claims 2937, can this be correct?  Doesn't gnumach support only 1024
> threads total?).

No, there is no such hard limit.  THREAD_MAX in mach_param.h is just used
for the starting size of some zalloc zones; since those zinit calls don't
use ZONE_EXHAUSTIBLE or ZONE_FIXED, these zones will grow as needed.

> One thing that would be useful is to make the timeout for message serving
> threads work.  What is required for that?

I don't know any reason it shouldn't work.
There is just the line:

  thread_timeout = global_timeout = 0; /* XXX */

in manage-multithread.c, which Thomas added in 1995 without any rationale
given in the log entry or comments (and I certainly don't recall it).
This might just have been to simplify debugging of something else at the time.
You could try removing that line and see what happens.