David Greenman wrote:
> Yes, I do - at least with the 512MB figure. That would be half of the 1GB
>KVA space and large systems really need that space for things like network
>buffers and other map regions.
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> What would be an acceptable upper limit? 256MB? 128MB? The test
> I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area
> before the number of vnodes stabilized, on a 1GB machine. I would say
> that a 128MB upper limit would be too small for a 4G machine. A 256MB
> limit ought to work for a 4G machine
It appears we're rapidly approaching the point where 32-bits isn't
enough. We could increase KVA - but that cuts into process VM space
(and a large machine is likely to have large processes).
The other option is moving away from a flat memory model: How about
putting some of the larger kernel-only data-structures into another
segment? The downside is that unless we want to start passing `far'
pointers around (which is both ugly and inefficient), we need to
make the pointer address space transparent to the compiler.
Of course, with proper data-hiding, this exercise is fairly trivial -
only the functions that physically reference the object need to know
where it is. But I don't think the kernel is structured in this way
(for good and valid reasons - CS theoreticians notwithstanding). And
any bugs (like `cheating' by not accessing data through the approved
mechanisms) will lead to fairly obscure panics (the address is
perfectly valid - it's just the wrong segment).
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message