On Tue, Jul 15, 2014 at 9:29 AM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Tuesday 15 July 2014 15:40:52 Rutledge Shawn wrote: >> Sounds like a good start, but with some limitations: it's done by periodic >> scanning; and Linux Documentation/vm/ksm.txt says >> >> KSM only operates on those areas of address space which an application >> has advised to be likely candidates for merging, by using the madvise(2) >> system call: int madvise(addr, length, MADV_MERGEABLE). >> … >> Applications should be considerate in their use of MADV_MERGEABLE, >> restricting its use to areas likely to benefit. KSM's scans may use a lot >> of processing power: some installations will disable KSM for that reason. >> >> cat /sys/kernel/mm/ksm/run => 0: so it's disabled on my system by default >> >> So we need to add madvise() calls to Qt to enable this, or is it done >> already on another layer? The only place I found any is in >> src/3rdparty/pcre/sljit/sljitUtils.c. But it sounds like the cost >> outweighs the benefit often enough that it has remained a cautious opt-in >> feature. > > We should *not* add that to Qt. > > The question is whether the user wants to do it. If they want to do it for the > application they're shipping because they believe there's a good chance that > the libraries they ship match the one in the operating system, they'll scan > the process map (/proc/self/maps) and advise which read-only sections of the > libraries they want to share. > > I repeat: this is an application action. Qt shall not do it. > >> Then I wonder if we could test, after getting it working, how different Qt >> has to be before it stops working. I don't suppose it's easy to track which >> de-duplicated pages came from which (ranges inside) files. > > It's possible any small change will be enough to cause problems. You want to > enable this only when there's a good chance that the library is identical, > from the very same build. > >> http://jak-linux.org/projects/hardlink/ claims to replace complete file >> duplicates with hard links; I will have to try it. But that is apparently >> also a periodic-scanning solution. > > That is a much better solution. If you replace the library with hardlinks or > symlinks, then the kernel knows it's the same file and then the pages > automatically get shared.
Unless you have some weird embedded use-case, all of this seems like a lot of work and worry with no benefit. Shipping all dependencies of a Qt GUI application is just not a big deal, as apparently X servers don't mind newer client libraries as far as I can tell. Ian _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
