X is consuming ~100 GiB of RAM(!)

[Ewen Chan]

Hi-Angel:

Actually, I tried running it with SLES12 SP2 (which would have a newer
kernel than SLES12 SP1) and the analysis software actually failed to run in
SLES12 SP2.

Tried it (not for this issue, just in general).

Didn't work.

The analysis software is not certified to run in SLES12 SP2, just as it is
not certified to run on the latest kernel. (The platform support
documention is listed by distro version, so whatever kernel comes with the
distro version is what the analysis software has been certfied to run on.)

I don't disagree with you that newer kernels comes with many benefits. But
when I can't guarantee its operation and the developer of the analysis
software doesn't support it beyond what they've published as supported
linux distros/versions in their platform support documentation - so if I
want to make sure that everything works per the developer of the analysis
software (as an end user), I would be advised to stay within what platforms
they have certified (and support, including kernels) because that is what
the analysis software developer can guarantee proper operation of their
software.

Believe me, if this was something that I was developing and/or have more
freedom and control over how it is developed, using the latest and greatest
technologies that would yield the greatest benefit would of course be the
best thing to do. But I don't have any say in it as an end user. And given
the number of versions/iterations of Linux kernels out there, it would be
physically impossible to persistently maintain and ensure that a software
that's 26 GB (when installed) will work persistently throughout the entire
software system for all of the kernel versions, as they are developed and
published.

That would be insane. There would be no end to the testing.

(Remember, my analysis script alone takes 4.5 days to run. Think about how
many kernels are available that's floating out there and now imagine that I
would have to test it against each of the kernels. And that's just in the
realm of mechanical engineering analysis domain. Doesn't include any other
engineering and/or physics domains.)

It's just not feasible nor practical for the analysis software developer to
do that.

Thanks.

Sincerely,
Ewen

On Fri, Dec 8, 2017 at 4:17 AM, Hi-Angel <hiangel999 at gmail.com> wrote:

> On 7 December 2017 at 19:22, Ewen Chan <chan.ewen at gmail.com> wrote:
> > Pros (for Linux): It's faster when it is running at runlevel 3.
>
> Oh, by the way, I forgot to mention — just a tiny detail you might be
> curious of. I'm pretty sure you're running some old kernel, however in
> every kernel release there's a bunch of improvements and refactoring
> across all subsystems — power/cpu schedulers, kernel drivers, memory
> management, etc. So by using a later kernel you could make your
> calculations even faster. For more details see this
> https://kernelnewbies.org/LinuxVersions
>
> There's also per-thread malloc cache in glibc-2.26 which improves
> results of some benchmarks too. In general, if you want more
> performance, running latest software is recommended.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20171208/2223d640/attachment.html>