Re: bug (trouble?) report on high mem support

[Martin J. Bligh]

> The readprofile output I sent earlier is pretty
> accurate.  I performed the test right after a reboot
> to the enterprise (64GB mem) kernel with a profile=2
> boot option.  I then ran our program, which reads in
> a 3.1GB file from an NFS mount, and outputs a 2.4GB file
> in another format to the same NFS mount.  Networking
> is achieved through an IBM Gigabit fiber card with 
> Intel e1000 chipset, which we have downloaded the
> latest source just to get it to work.  But network
> throughput looks great.  Other programs using the 
> NFS mounts work fine, so I'm pretty sure it's not
> a network issue.
> 
> The smp kernel (no 64GB mem support) completed the
> file conversion in 3.5 hours.  Previous attempts 
> with the enterprise kernel (64GB mem support) had
> to be aborted after 3 days and only started to write
> the converted file to disk by then.  This application
> does not run multi-threaded, but we will have 
> multiple users running the program on separate
> file conversions simultaneously.  Hence the need
> for lots of memory.
> 
> I guess the main question at this point is whether
> our hardware supports high memory, and then which 
> patches or kernel upgrades can correct our problem.
> If we upgrade the entire kernel, which release 
> would you recommend for a stable production machine
> with >4GB memory?  If there are swap improvements,
> we also need whatever we can get in that area.

You mention "64Gb support" or "no 64Gb support" throughout 
this - have you tried a kernel with 4Gb support? That'd
give you the HIGHMEM bounce buffering still. One step at a
time ;-)

M.