Re: 3.5+0.5GB user/kernel split - supported in EL-3.0??

On Wed, 10 Sep 2003, Ramki Balasubramanian wrote:

> We could really use CONFIG_SMP and HIGHMEM4G (not HIGHMEM64G),
> but I'm assuming there's some rationale behind redhat not choosing
> to have this option?

Testing and certification.  The more kernels there are, the
less well they get tested and the more work it would be for
anybody to certify all of them.

Also think about 3rd party drivers, etc...

> > If you want more than 3GB address space for your programs,
> > you can just use the 4/4 split kernel, which gives you a
> > full 3.9 GB of program address space...
> 
> This was reported (earlier in this list) to have about 20-30%
> penalty. What would be the best option for someone to keep
> the > 3GB userspace access and minimize the penalty?

The penalty is only for kernel intensive workloads, and
even then it's not always a clear cut number.

In a few benchmarks we have found the 4/4 kernel to be
faster than the normal kernel, simply because the system
could access all memory directly in kernel space and had
more place to store inodes ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


--
Taroon-beta-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/taroon-beta-list