| |||||||||||||
Linus saw it comingLinus saw it comingPosted Feb 12, 2008 17:12 UTC (Tue) by proski (subscriber, #104)Parent article: vmsplice(): the making of a local root exploit Linus actually criticized vmsplice() from the performance standpoint. But his reference to "VM games" seems highly relevant to this issue. From http://kerneltrap.org/node/6506: "I claim that Mach people (and apparently FreeBSD) are incompetent idiots. Playing games with VM is bad. memory copies are _also_ bad, but quite frankly, memory copies often have _less_ downside than VM games, and bigger caches will only continue to drive that point home."Having more than one way to do something has a downside. The less used way is less tested and less reviewed for security.
(Log in to post comments)
Linus saw it coming Posted Feb 12, 2008 18:55 UTC (Tue) by eSk (subscriber, #45221) [Link] Except that vmsplice() does not fall under the category of "VM games" since it does not actually go about modifying the page tables of the applications. Also Linus was referring to the performance downsides of playing "VM games". Considering that splice() and vmsplice() were added purely for performance reasons it would have been quite hypocritical to add vmsplice() to improve performance (if vmsplice() actually did play "VM games", that is). I'm not familiar with his criticism of vmsplice() from the performance standpoint that you refer to.It should also be noted that Linus was in this quote quite wrong in his contempt for FreeBSD developers. FreeBSD developers were (and are) very much aware of the issues at hand. That's why the zero-copy socket option was disabled by default.
Linus saw it coming Posted Feb 12, 2008 19:14 UTC (Tue) by rfunk (subscriber, #4054) [Link] No, Linus was promoting vmsplice there, not criticizing it.
Bigger caches ? Where ? Posted Feb 12, 2008 21:15 UTC (Tue) by khim (subscriber, #9252) [Link] This is place where Linus misses the point completely: there are no "bigger cache sizes". There will never be "bigger cache sizes". Never. Pentium had 16 KiB L1 cache in 1993, PowerPC 601 had 32 Kib cache in 1993! Today... Latest and greatest Itanium has 16 KiB L1D + 16 KiB L1I cache, Inter Core 2 uses 32 KiB L1D + 32 KiB L1I caches and biggest caches of POWER6 and AMD Phenom are reaching just 64 KiB L1D + 64 KiB L1I! Basically two times increase in 15 years! I'm not sure we'll ever see anything bigger than 256KiB "cache" (local RAM) in Cell. So while "cheep, slow" RAM is abundant resource L1 is as precious today as it was 10 years ago and as it will be 10 years from now! Use L1 very sparingly!
Bigger caches ? Where ? Posted Feb 12, 2008 22:04 UTC (Tue) by zlynx (subscriber, #2285) [Link] I think you're missing the point here. L1 cache is, as I understand it, about as fast as chip registers. So that 16 KB cache has grown faster and faster over the years. What is L2 and L3 cache now is *huge* and is likely as fast if not faster than that 1993 Pentium's 16 KB cache. And all chip cache is hugely faster than system RAM. Look at benchmarks that show the optimization of certain algorithms. When they use cache-optimized blocks instead of streaming over the entire data set, performance improves a hundred fold in some cases.
Bigger caches ? Where ? Posted Feb 12, 2008 22:51 UTC (Tue) by man_ls (subscriber, #15091) [Link] Moore's law is still valid: transistors on a chip are doubling every 18 months. However clock speeds are not getting any faster; my old PIV was running at 3.2 GHz, and you seldom see those speeds nowadays. So guess where many (if not most) of all those extra transistors are going. Yep, into the caches.
Bigger caches ? Where ? Posted Feb 13, 2008 20:23 UTC (Wed) by hmh (subscriber, #3838) [Link] In mainstream consumer CPUs, maybe the clocks have stabilized (which IS a good thing, we already waste too much power just to do office work). Look at the IBM Power6 for some high-clock cores...
Bigger caches ? Where ? Posted Feb 21, 2008 9:53 UTC (Thu) by renox (subscriber, #23785) [Link] >Look at the IBM Power6 for some high-clock cores... Except that apparently they had a lot of difficulty ramping up the clock.. Plus their CPU does *in order* integer processing which induce a loss of efficiency.. It'd be interesting to have a study which analyse whether going in order for integer processing to increase the clock really did improve performance or if it was just a marketing gimmick a la P4.
Power 6 clock high-score and real performance Posted Feb 23, 2008 17:14 UTC (Sat) by anton (guest, #25547) [Link] It'd be interesting to have a study which analyse whether going in order for integer processing to increase the clock really did improve performanceTake a look at SPEC CPU 2006 results. Last I looked, a 4.7GHz Power6 had similar speed to a 3GHz Core 2 Duo 6850 in both SPECint2006 and SPECfp2006 results.
Bigger caches ? Where ? Posted Feb 21, 2008 9:46 UTC (Thu) by renox (subscriber, #23785) [Link] >This is place where Linus misses the point completely: there are no "bigger cache sizes". There will never be "bigger cache sizes". Never. Pentium had 16 KiB L1 Funny how you restrict the meaning of 'bigger cache size' to 'L1 cache size' to "make your point". Sure L1 won't grow, but L2 and L3 cache are also cache you know?
Bigger caches ? Where ? Posted Mar 9, 2008 23:16 UTC (Sun) by phip (guest, #1715) [Link] > There will never be "bigger cache sizes". Never. You should check out PA-RISC. They have L1 D-caches up to 2048K.
|
|||||||||||||