Natterings about history files
davidsen at tmr.com
Thu Mar 8 18:46:35 UTC 2001
In article <Pine.HPX.4.10.10103081040570.3047-100000 at merle.acns.nwu.edu>,
Nicholas Geovanis <n-geovanis at nwu.edu> wrote:
| On 8 Mar 2001, bill davidsen wrote:
| > I suspect things have to change anyway, the size of files is getting
| > near the per-process address space of many systems, and at some point
| > soon we will lose the ability to mmap() on those systems. I have to do
| > serious hacks to AIX executables to get more than the default 256MB
| > process data space, and I can only have 2GB with the fix. This is
| > address space, not files size, different ugliness.
| You should only have to compile with "-bmaxdata", right? (OK, I'm
| assuming that you're using IBM's compiler) And the 2GB limit is only for
| the data segment; stack and program text are in separate segments and
| don't count against it.
Yes, and why that's not the default for INN on AIX I couldn't say. But
since I have more machines than licenses, I generally avoid recompiling
and moving if I can, so the ugly octal patch got used on several machines.
| If you're not using IBM's compiler, yes, you have to do the one-line shell
| script hack to enable maxdata in the executable. But frankly, if you're
| really trying to optimise the code for AIX, you want the IBM compiler.
I use it, but I wish I could use gcc without performance issues.
Moving the compiled source tree and doing 'make install' always results
in an attempt at recompile, for what reason I haven't determined. Since
I can work around, I am for now.
The original point though, is that 2GB is a popular limit on use data
space (for mmap() operations), and we can't go on indefinitely using
mmap() and mlock() on things which are going.
Today it's a discussion point, down the line it will become an issue.
News is growing faster than address space.
bill davidsen <davidsen at tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
More information about the inn-workers