[Interest] Qt5, XCB and X11

[Ian Monroe]

On Tue, Jul 15, 2014 at 9:29 AM, Thiago Macieira
<thiago.macieira at 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