CINXE.COM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>LKML: Ingo Molnar: Re: Industry db benchmark result on recent 2.6 kernels</title><link href="/css/message.css" rel="stylesheet" type="text/css" /><link href="/css/wrap.css" rel="alternate stylesheet" type="text/css" title="wrap" /><link href="/css/nowrap.css" rel="stylesheet" type="text/css" title="nowrap" /><link href="/favicon.ico" rel="shortcut icon" /><script src="/js/simple-calendar.js" type="text/javascript"></script><script src="/js/styleswitcher.js" type="text/javascript"></script><link rel="alternate" type="application/rss+xml" title="lkml.org : last 100 messages" href="/rss.php" /><link rel="alternate" type="application/rss+xml" title="lkml.org : last messages by Ingo Molnar" href="/groupie.php?aid=18" /><script> var _paq = window._paq = window._paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(["setDoNotTrack", true]); _paq.push(["disableCookies"]); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//m.lkml.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script></head><body onload="es.jasper.simpleCalendar.init();" itemscope="itemscope" itemtype="http://schema.org/BlogPosting"><table border="0" cellpadding="0" cellspacing="0"><tr><td width="180" align="center"><a href="/"><img style="border:0;width:135px;height:32px" src="/images/toprowlk.gif" alt="lkml.org" /></a></td><td width="32">聽</td><td class="nb"><div><a class="nb" href="/lkml"> [lkml]</a> 聽 <a class="nb" href="/lkml/2005"> [2005]</a> 聽 <a class="nb" href="/lkml/2005/4"> [Apr]</a> 聽 <a class="nb" href="/lkml/2005/4/1"> [1]</a> 聽 <a class="nb" href="/lkml/last100"> [last100]</a> 聽 <a href="/rss.php"><img src="/images/rss-or.gif" border="0" alt="RSS Feed" /></a></div><div>Views: <a href="#" class="nowrap" onclick="setActiveStyleSheet('wrap');return false;">[wrap]</a><a href="#" class="wrap" onclick="setActiveStyleSheet('nowrap');return false;">[no wrap]</a> 聽 <a class="nb" href="/lkml/mheaders/2005/4/1/74" onclick="this.href='/lkml/headers'+'/2005/4/1/74';">[headers]</a>聽 <a href="/lkml/bounce/2005/4/1/74">[forward]</a>聽 </div></td><td width="32">聽</td></tr><tr><td valign="top"><div class="es-jasper-simpleCalendar" baseurl="/lkml/"></div><div class="threadlist">Messages in this thread</div><ul class="threadlist"><li class="root"><a href="/lkml/2005/3/28/161">First message in thread</a></li><li><a href="/lkml/2005/4/1/28">Ingo Molnar</a><ul><li><a href="/lkml/2005/4/1/59">Paul Jackson</a><ul><li class="origin"><a href="/lkml/2005/4/1/117">Ingo Molnar</a><ul><li><a href="/lkml/2005/4/1/117">Paul Jackson</a></li></ul></li></ul></li></ul></li></ul></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerl.gif" width="32" height="32" alt="/" /></td><td class="c" rowspan="2" valign="top" style="padding-top: 1em"><table><tr><td><table><tr><td class="lp">Date</td><td class="rp" itemprop="datePublished">Fri, 1 Apr 2005 12:34:52 +0200</td></tr><tr><td class="lp">From</td><td class="rp" itemprop="author">Ingo Molnar <></td></tr><tr><td class="lp">Subject</td><td class="rp" itemprop="name">Re: Industry db benchmark result on recent 2.6 kernels</td></tr></table></td><td></td></tr></table><pre itemprop="articleBody"><br />* Paul Jackson <pj@engr.sgi.com> wrote:<br /><br />> > It has to be made sure that H1+H2+H3 != H4+H5+H6,<br />> <br />> Yeah - if you start trying to think about the general case here, the <br />> combinations tend to explode on one.<br /><br />well, while i dont think we need that much complexity, the most generic <br />case is a representation of the actual hardware (cache/bus) layout, <br />where separate hardware component types have different IDs.<br /><br />e.g. a simple hiearchy would be:<br /><br /> ____H1____<br /> _H2_ _H2_<br /> H3 H3 H3 H3<br /> [P1] [P2] [P3] [P4]<br /><br />Then all that has to happen is to build a 'path' of ids (e.g. "H3,H2,H3" <br />is a path), which is a vector of IDs, and an array of already measured <br />vectors. These IDs never get added so they just have to be unique per <br />type of component.<br /><br />there are two different vectors possible: H3,H2,H3 and H3,H2,H1,H2,H3, <br />so two measurements are needed, between P1 and P2 and P1 and P3. (the <br />first natural occurence of each path)<br /><br />this is tree walking and vector building/matching. There is no <br />restriction on the layout of the hierarchy, other than it has to be a <br />tree. (no circularity) It's easy to specify such a tree, and there are <br />no 'mixup' dangers.<br /><br />> I'm thinking we get off easy, because:<br />> <br />> 1) Specific arch's can apply specific short cuts.<br />> <br />> My intuition was that any specific architecture, when it<br />> got down to specifics, could find enough ways to cheat<br />> so that it could get results quickly, that easily fit<br />> in a single 'distance' word, which results were 'close<br />> enough.'<br /><br />yes - but the fundamental problem is already that we do have per-arch <br />shortcuts: the cache_hot value. If an arch wanted to set it up, it could <br />do it. But it's not easy to set it up and the value is not intuitive. So <br />the key is to make it convenient and fool-proof to set up the data - <br />otherwise it just wont be used, or will be used incorrectly.<br /><br />but i'd too go for the simpler 'pseudo-distance' function, because it's <br />so much easier to iterate through it. But it's not intuitive. Maybe it <br />should be called 'connection ID': a unique ID for each uniqe type of <br />path between CPUs. An architecture can take shortcuts if it has a simple <br />layout (most have). I.e.:<br /><br /> sched_cpu_connection_type(int cpu1, int cpu2)<br /><br />would return a unique type ID for different. Note that 'distance' (or <br />'memory access latency', or 'NUMA factor') as a unit is not sufficient, <br />as it does not take cache-size nor CPU speed into account, which does <br />play a role in the migration characteristics.<br /><br /> Ingo<br />-<br />To unsubscribe from this list: send the line "unsubscribe linux-kernel" in<br />the body of a message to majordomo@vger.kernel.org<br />More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a><br />Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a><br /><br /></pre></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerr.gif" width="32" height="32" alt="\" /></td></tr><tr><td align="right" valign="bottom"> 聽 </td></tr><tr><td align="right" valign="bottom">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerl.gif" width="32" height="32" alt="\" /></td><td class="c">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerr.gif" width="32" height="32" alt="/" /></td></tr><tr><td align="right" valign="top" colspan="2"> 聽 </td><td class="lm">Last update: 2005-04-06 13:31 聽聽 [from the cache]<br />漏2003-2020 <a href="http://blog.jasper.es/"><span itemprop="editor">Jasper Spaans</span></a>|hosted at <a href="https://www.digitalocean.com/?refcode=9a8e99d24cf9">Digital Ocean</a> and my Meterkast|<a href="http://blog.jasper.es/categories.html#lkml-ref">Read the blog</a></td><td>聽</td></tr></table><script language="javascript" src="/js/styleswitcher.js" type="text/javascript"></script></body></html>