Bug #1961
open
investigate stopping uniquifying CTF information
0%
Description
We uniquify the CTF information in the kernel against genunix (and ip) to save space. This was probably really important when CTF was first added to the system, but is very likely to be much less important now, and causes a bunch of problems (since it ties the version of every module to the version of genunix with which it was built, requiring anyone delivering modules separately to know, at least, about the magic used for KU patches, but generally just making a mess).
Talking with Adam about the problems that mis-matches posed for DTrace (spurious failures of anything dtrace-based, due to mismatched and thus incorrect type information) he suggested that perhaps uniquification wasn't so important any more.
I've done some basic investigation of this, using both DWARF and stabs sourced CTF
Random driver module (bge): stabs-before: 76025(.SUNW_ctf) -- 2240 types stabs-after: 92253(.SUNW_ctf) -- 3239 types dwarf-before: 8449(.SUNW_ctf) -- 249 types dwarf-after: 47050(.SUNW_ctf) -- 1951 types
Note that while in the DWARF case, the lack of uniquification hurts us a lot more, it still doesn't even bring us equal to a uniquified, stabs-based, module because DWARF defaults to only producing information for referenced things, rather than everything.
Random larger system module (sys/nfs): stabs-before: 120842(.SUNW_ctf) -- 4166 types stabs-after: 139938(.SUNW_ctf) -- 5319 types dwarf-before: 37073(.SUNW_ctf) -- 1653 types dwarf-after: 80578(.SUNW_ctf) -- 3575 types
Updated by Rich Lowe over 11 years ago
For DWARF-based CTF this increases the total size from 3.5M to 6.3M (that's the size of the sections presented by /system/object, which includes .SUNW_ctf). Figures for stabs from Studio will undoubtedly be higher.
The average module's CTF information grows by about 27K (which is unfortunately high); the average is being pulled up primarily with modules associated with ip (ip, mac, tcp, spdsock, keysock, udp, icmp).
This is based on a running 64bit system, with its natural set of modules loaded.
Updated by Rich Lowe over 11 years ago
With stabs /system/object increases from 3.9M to 11M, average .SUNW_ctf increase of 73KB.
Updated by Alexander Eremin over 11 years ago
Rich, could you please add some lines here about possible increazing of miniroot/bootarchive size (from your tests).
Updated by Rich Lowe over 11 years ago
A simulation was included in the RTI:
| compiler | platform | unique | size | |----------+----------+--------+------| | studio | amd64 | no | 82M | | studio | amd64 | yes | 50M | | studio | i386 | no | 78M | | studio | i386 | yes | 47M | | gcc | amd64 | no | 57M | | gcc | amd64 | yes | 45M | | gcc | i386 | no | 51M | | gcc | i386 | yes | 39M | This is an approximation of boot archive growth, the 'size' column approximates the kernel module constituents of the boot archive. It does not attempt to estimate likely runtime impact on an arbitrary system.
That would be a simulation of the worst case boot archive with every module potentially present, present. For growth obviously subtract "yes" from "no".
Updated by Rich Lowe over 6 years ago
The problem with this is that DTrace only handles forward declarations, and specifically opaque types such as <p>cred_t</p> because the CTF uniquification step chooses the concrete type when it finds one.
This especially noticeable with types such has cred_t, which are both opaque and all over the kernel.
I have code in a branch on github, https://github.com/richlowe/illumos-gate/tree/ctf/no-unique
which attempts to rectify this by making DTrace search harder for a concrete type in these cases, but I am unsure that it is correct, and am even more unsure of how to thoroughly test it.
It may seem reasonable to argue that DTrace being unable to see inside 'cred_t' is in fact, correct, in the sense that cred_t is opaque and it is therefore doing the right thing. While such an argument is correct, it is also particularly kind.