Natterings about history files

[bill davidsen]

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.
| Honest. 

  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.