Yes: instruction cache. Big programs are slow programs.
That's too simplistic. Programs with hot code sections that don't fit in icache are slow programs. If your program is huge but you spend all your time in a small fraction of code (typical) that fits in icache (no idea if that's typical), it's fine from a cache performance perspective.
I think joechung is more right here, icache in this instance means inode cache; the CPU D-Cache and I-Cache (not to be confused the file-system related dcache and icache for dentry cache and inode cache respectively) are of fixed size and you couldn't have "bloat" there. The FS inode cache is more likely to be bloated given the larger upper limit for disk storage compared to CPU cache.
No way, for three reasons. (1) Saying "icache" and meaning anything other than "instruction cache" would be an obvious recipe for confusion, and Linus is not stupid. (2) It makes excellent sense with the obvious "instruction cache" meaning: "our icache footprint" means "the number of instruction cache lines occupied by kernel code". (3) It makes no sense with the "inode cache" meaning: how could a growth in the amount of code in the kernel possibly have anything much to do with the size or the occupancy of the inode cache?
And you would be absolutely right. Thanks for the good analysis :-)