What you are looking for can be found on the Ohloh website, which by the way indexes the Linux GIT repository.
There you will see a graph showing you how much the kernel has changed over 1 yr, 3 yrs, 5 yrs, 10 yrs or All. By default it will show you the statistics for the source code but you can also get statistics about Languages, Committers, Commits. You can then manually calculate the change %. The change in source code between 2010 and 2011 is up 11.4%.
Kernel is a bit of a misnomer. The Linux kernel is comprised of several proceses/threads + the modules (lsmod) so to get a complete picture you'd need to look at the whole ball and not just a single component.
Incidentally mine shows slabtop:
Active / Total Size (% used) : 173428.30K / 204497.61K (84.8%)
The man page for slabtop also had this to say:
The slabtop statistic header is tracking how many bytes of slabs are being used and it not a measure of physical memory. The 'Slab' field in the /proc/meminfo file is tracking information about used slab physical memory.
Dropping caches
Dropping my caches as @derobert suggested in the comments under your question does the following for me:
$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$
Active / Total Size (% used) : 61858.78K / 90524.77K (68.3%)
Sending a 3 does the following: free pagecache, dentries and inodes. I discuss this more in this U&L Q&A titled: Are there any ways or tools to dump the memory cache and buffer?". So 110MB of my space was being used by just maintaining the info regarding pagecache, dentries and inodes.
Additional Information
So how much RAM is my Kernel using?
This picture is a bit foggier to me, but here are the things that I "think" we know.
Slab
We can get a snapshot of the Slab usage using this technique. Essentially we can pull this information out of /proc/meminfo.
$ grep Slab /proc/meminfo
Slab: 100728 kB
Modules
Also we can get a size value for Kernel modules (unclear whether it's their size from on disk or when in RAM) by pulling these values from /proc/modules:
$ awk '{print $1 " " $2 }' /proc/modules | head -5
cpufreq_powersave 1154
tcp_lp 2111
aesni_intel 12131
cryptd 7111
aes_x86_64 7758
Slabinfo
Much of the details about the SLAB are accessible in this proc structure, /proc/slabinfo:
$ less /proc/slabinfo | head -5
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_ffff8801f2b30000 0 0 320 25 2 : tunables 0 0 0 : slabdata 0 0 0
fuse_request 100 125 632 25 4 : tunables 0 0 0 : slabdata 5 5 0
fuse_inode 21 21 768 21 4 : tunables 0 0 0 : slabdata 1 1 0
Dmesg
When your system boots there is a line that reports memory usage of the Linux kernel just after it's loaded.
$ dmesg |grep Memory:
[ 0.000000] Memory: 7970012k/9371648k available (4557k kernel code, 1192276k absent, 209360k reserved, 7251k data, 948k init)
References
Best Answer
After some research, I can now answer my own question. The maximum isochronous packet size for high speed devices is 1024 bytes. There can be up to three packets per microframe, and a microframe is 125 microseconds wide, meaning that there can be 8 microframes transferred per millisecond.
This gives us a maximum bandwidth allocation of 3*1024*8*1000 = 23.438 MB/s (edit: used to say mbps)
The wMaxPacketSize parameter is a two byte value which contains a bit mapping of both the maximum size per packet and number of packets per microframe is stored.
Thus the bandwidth allocation is as follows:
(packets/microframe) * (max_packet_size) * (8 microframes/millisecond) * (1000ms/s)
It's also important to note that per USB 2.0 spec, only 80% of the total amount of bandwidth can be allocated to periodic transfers such as isochronous and interrupt transfers.