Project

General

Profile

Bug #1961

investigate stopping uniquifying CTF information

Added by Rich Lowe about 8 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2012-01-07
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:

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

History

#1

Updated by Rich Lowe about 8 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.

#2

Updated by Rich Lowe about 8 years ago

With stabs /system/object increases from 3.9M to 11M, average .SUNW_ctf increase of 73KB.

#3

Updated by Alexander Eremin almost 8 years ago

Rich, could you please add some lines here about possible increazing of miniroot/bootarchive size (from your tests).

#4

Updated by Rich Lowe almost 8 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".

#5

Updated by Rich Lowe almost 3 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.

Also available in: Atom PDF