> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:11 EST