> "Uh, I'd love to say we have a plan," Torvalds replied to applause and chuckles from the audience. "I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary.
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?
