blogs.oracle.com.html - webdump_tests - Testfiles for webdump
(HTM) git clone git://git.codemadness.org/webdump_tests
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
---
blogs.oracle.com.html (134476B)
---
1 <!DOCTYPE html>
2 <html lang="en-US" class="no-js">
3
4 <head>
5 <!-- Avoid FOUC issue in FF with async loading of style sheets -->
6 <style>
7 body {
8 opacity: 1;
9 }
10 </style>
11 <title>Syscall latency... and some uses of speculative execution</title>
12 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
13 <meta charset="utf-8">
14 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
15 <link rel="alternate" type="application/rss+xml" href="https://blogs.oracle.com/rss">
16 <!-- $meta_tags -->
17 <meta name="country" content="">
18 <meta name="contenttype_id" content="WM147046">
19 <meta name="description" content="An in-depth exploration into why syscall latency increased on some x86 kernels in recent kernels. ">
20 <link rel="canonical" href="">
21 <meta name="host_name" content="https://blogs.oracle.com">
22 <meta name="title" content="Syscall latency... and some uses of speculative execution">
23 <meta name="blog_name" content="Oracle Linux Blog">
24 <meta name="author" content="Ankur">
25 <meta name="keywords" content="Technologies,Linux Kernel Development">
26 <meta name="publish_date" content="September 12, 2023">
27 <meta name="siteid" content="us">
28 <meta name="Language" content="">
29 <meta name="robots" content="index, follow">
30 <meta name="audience" content="">
31 <meta name="product" content="">
32 <meta property="og:type" content="blog">
33 <meta property="og:title" content="Syscall latency... and some uses of speculative execution">
34 <meta property="og:image" content="https://blogs.oracle.com/content/published/api/v1.1/assets/CONTCF8836A82B014903A5283C76DE901346/Medium?format=jpg&channelToken=3189ef66cf584820b5b19e6b10792d6f">
35 <meta property="og:description" content="An in-depth exploration into why syscall latency increased on some x86 kernels in recent kernels. ">
36 <meta property="og:url" content="https://blogs.oracle.com/linux/post/syscall-latency">
37 <meta name="category" content="Technologies,Linux Kernel Development">
38 <meta name="twitter:card" content="summary_large_image">
39 <meta name="twitter:title" content="" />
40 <meta name="twitter:description" content="" />
41 <meta name="twitter:image" content="" />
42 <meta name="google-site-verification" content="OVRFC0CuVBZNzlfzelWzFIN7D4gCrVfzsfmMWvteKHs" />
43 <link rel="alternate" type="application/rss+xml" class="rss-link" title="Oracle Blogs"
44 href="https://blogs.oracle.com/rss">
45
46
47 <!-- <link data-wscss href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/css/blogs-style.css" rel="preload" as="style" onload="this.rel='stylesheet';" onerror="this.rel='stylesheet'"> -->
48 <link rel="preload" onload="this.rel='stylesheet'" href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/css/blogs-style.css" as="style" />
49 <link rel="preload" onload="this.rel='stylesheet'" href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/css/oracle-style.css" as="style" />
50
51 <!-- favicon -->
52 <link rel="icon" href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/img/logo.ico" type="image/x-icon" />
53 <link rel="shortcut icon" href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/img/logo.ico" type="image/x-icon" />
54
55 <link rel="preconnect" href="https://c.go-mpulse.net" crossorigin />
56 <link rel="preconnect" href="https://s.go-mpulse.net" crossorigin />
57 <link rel="preconnect" href="https://tms.oracle.com" crossorigin />
58 <link rel="preconnect" href="https://www.facebook.com" crossorigin />
59 <link rel="preconnect" href="https://connect.facebook.net" crossorigin />
60 <link rel="preconnect" href="https://www.oracle.com" crossorigin />
61 <link rel="preconnect" href="https://consent.trustarc.com" crossorigin />
62 <link rel="preconnect" href="https://www.oracleimg.com" crossorigin />
63 <link rel="preconnect" href="https://oracle.112.2o7.net" crossorigin />
64 <link rel="preconnect" href="https://trial-eum-clientnsv4-s.akamaihd.net" crossorigin />
65 <link rel="preconnect" href="https://trial-eum-clienttons-s.akamaihd.net" crossorigin />
66 <link rel="preconnect" href="https://d.oracleinfinity.io" crossorigin />
67 <link rel="preconnect" href="https://www.googletagmanager.com" crossorigin />
68
69 <link rel="dns-prefetch" href="https://static.ocecdn.oraclecloud.com" />
70 <link rel="dns-prefetch" href="https://c.go-mpulse.net" />
71 <link rel="dns-prefetch" href="https://s.go-mpulse.net" />
72 <link rel="dns-prefetch" href="https://tms.oracle.com" />
73 <link rel="dns-prefetch" href="https://www.facebook.com" />
74 <link rel="dns-prefetch" href="https://connect.facebook.net" />
75 <link rel="dns-prefetch" href="https://www.oracle.com" />
76 <link rel="dns-prefetch" href="https://consent.trustarc.com" />
77 <link rel="dns-prefetch" href="https://www.oracleimg.com" />
78 <link rel="dns-prefetch" href="https://oracle.112.2o7.net" />
79 <link rel="dns-prefetch" href="[https://trial-eum-clientnsv4-s.akamaihd.net" />
80 <link rel="dns-prefetch" href="https://trial-eum-clienttons-s.akamaihd.net" />
81 <link rel="dns-prefetch" href="https://d.oracleinfinity.io" />
82 <link rel="dns-prefetch" href="https://www.googletagmanager.com" />
83
84 <script type="text/javascript" src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/js/jquery/jquery-min.js"
85 onload="$('head link[data-reqjq][rel=preload]').each(function(){var a = document.createElement('script');a.async=false;a.src=$(this).attr('href');this.parentNode.insertBefore(a, this);});$(function(){$('script[data-reqjq][data-src]').each(function(){this.async=true;this.src=$(this).data('src');});});"></script>
86
87 <!-- <script type="text/javascript" src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/js/blogs-script.js"></script> -->
88
89
90 <!--<link data-wsjs data-reqjq href="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/js/blogs-script.js" rel="preload" as="script">->
91
92 <script type="text/javascript" src="http://webstandards.us.oracle.com:9292/global_assets_v22.9.3/assets/js/redwood-blogs.js"></script> -->
93
94
95 <script id="scsRenderInfo" type="application/json">{"sitePrefix":"../","pageModel":{"properties":{"title":"Blog Theme - Details","pageLayout":"post-detail.html","mobileLayout":"","pageDescription":"","keywords":"","hideFromSearchEngines":false,"styles":[],"header":" ","footer":"","noIndex":false,"noFollow":false,"noArchive":false,"noSnippet":false,"isCobrowseEnabled":false,"overrideWebAnalytics":false,"webAnalyticsScript":null},"slots":{"post-id":{"components":["a37b49d5-e11f-4e1f-a5e0-fd37af71a288"],"grid":"<div class=\"scs-row\"><div class=\"scs-col\" style=\"width: 100%;\"><div id=\"a37b49d5-e11f-4e1f-a5e0-fd37af71a288\"></div></div></div>","preRenderedByController":true},"blog-search1":{"components":[],"grid":""},"homepage-banner":{"components":["c30bb2b5-2186-4cd6-aeb8-2f23c0d9360c"],"grid":"<div class=\"scs-row\"><div class=\"scs-col\" style=\"width: 100%;\"><div id=\"c30bb2b5-2186-4cd6-aeb8-2f23c0d9360c\"></div></div></div>"},"search":{"components":[],"grid":""},"recent-posts":{"components":[],"grid":""},"category-id":{"components":[],"grid":""},"blogs-category-nav":{"components":["f62eb3cd-6ac8-407d-9e06-69cbbc8d821e"],"grid":"<div class=\"scs-row\"><div class=\"scs-col\" style=\"width: 100%;\"><div id=\"f62eb3cd-6ac8-407d-9e06-69cbbc8d821e\"></div></div></div>","preRenderedByController":true},"Next-Previous-Posts":{"components":["a057a3dc-2397-4b35-88dc-e9904a3f1789"],"grid":"<div class=\"scs-row\"><div class=\"scs-col\" style=\"width: 100%;\"><div id=\"a057a3dc-2397-4b35-88dc-e9904a3f1789\"></div></div></div>","preRenderedByController":true}},"componentInstances":{"c30bb2b5-2186-4cd6-aeb8-2f23c0d9360c":{"type":"scs-component","id":"Blogs-Email-Subscription","data":{"actions":"","alignment":"fill","assets":"","borderColor":"#808080","borderRadius":0,"borderStyle":"none","borderWidth":1,"componentId":"Blogs-Email-Subscription","componentName":"Blogs-Email-Subscription","componentFactory":"","componentLayout":"default","contentId":"","contentLayoutCategory":"","contentPlaceholder":false,"contentTypes":[],"contentViewing":"","customRenderComplete":false,"customSettingsData":{},"componentConfig":{"id":"Blogs-Email-Subscription","settingsData":{"settingsHeight":0,"settingsWidth":0,"settingsRenderOption":"none","componentLayouts":[],"styles":[{"name":"Medium Green","class":"Ora-Paragraph-Banner-default-style"},{"name":"Dark Green","class":"ora-paragraph-banner-dark-green"},{"name":"Orange","class":"ora-paragraph-banner-orange"},{"name":"Teal","class":"ora-paragraph-banner-teal"},{"name":"Medium Teal","class":"ora-paragraph-banner-medium-teal"},{"name":"Blue","class":"ora-paragraph-banner-blue"},{"name":"Medium Brown","class":"ora-paragraph-banner-medium-brown"},{"name":"Granite","class":"ora-paragraph-banner-granite"},{"name":"Ecru","class":"ora-paragraph-banner-ecru"},{"name":"Fog Blue","class":"ora-paragraph-banner-fog-blue"},{"name":"Yellow","class":"ora-paragraph-banner-yellow"},{"name":"Dark Brown","class":"ora-paragraph-banner-dark-brown"}],"triggers":[],"actions":[]}},"description":"","detailPageId":"","height":"","initialized":true,"isCaaSLayout":false,"linkType":"scs-link-action","marginBottom":0,"marginLeft":0,"marginRight":0,"marginTop":0,"nestedComponents":[{"id":"oraParagraphBannerCtaText","type":"scs-button","data":{"marginBottom":0,"marginLeft":0,"marginRight":0,"marginTop":0,"styleClass":"scs-button-secondary-style","useStyleClass":"true","visible":true,"width":0}}],"renderOnAccess":"","styleClass":"","styleClassName":"","seeded":false,"useStyleClass":"true","visible":true,"visibleOnMobile":"","visibleNestedComponents":[],"width":0}},"a37b49d5-e11f-4e1f-a5e0-fd37af71a288":{"type":"scs-component","id":"scs-contentplaceholder","data":{"actions":"","alignment":"fill","assets":"","borderColor":"#808080","borderRadius":0,"borderStyle":"none","borderWidth":1,"componentId":"","componentName":"","componentFactory":"","componentLayout":"","contentId":"","contentLayoutCategory":"Blogs-Redwood-Post-Detail-Layout","contentPlaceholder":true,"contentTypes":["Blog-Post","Syndicated-Blog-Post"],"contentTypeDisplayName":"","contentTypeCategory":"ContentType","contentViewing":"","customRenderComplete":false,"customSettingsData":"","componentConfig":"","description":"","detailPageId":"105","height":"","initialized":true,"isCaaSLayout":true,"linkType":"scs-link-action","marginBottom":5,"marginLeft":5,"marginRight":5,"marginTop":5,"nestedComponents":[],"renderOnAccess":"","styleClass":"","styleClassName":"","seeded":true,"useStyleClass":"true","visible":true,"visibleOnMobile":"","visibleNestedComponents":[],"width":0},"preRenderedByController":true},"f62eb3cd-6ac8-407d-9e06-69cbbc8d821e":{"type":"scs-component","id":"Blogs-Redwood-Category-Nav","data":{"actions":"","alignment":"fill","assets":"","borderColor":"#808080","borderRadius":0,"borderStyle":"none","borderWidth":1,"componentId":"sampleComp","componentName":"Blogs-Redwood-Category-Nav","componentFactory":"","componentLayout":"default","contentId":"","contentLayoutCategory":"","contentPlaceholder":false,"contentTypes":[],"contentTypeCategory":"ContentType","contentViewing":"","customRenderComplete":false,"customSettingsData":{"taxonomyId":"6BC2FEFCC79B49D7A757708E6D9BE2CB"},"componentConfig":{"id":"sample-component","settingsData":{"settingsHeight":240,"settingsWidth":300,"settingsRenderOption":"dialog","componentLayouts":[{"name":"default","displayName":"IMAGE_LEFT_LAYOUT"},{"name":"right","displayName":"IMAGE_RIGHT_LAYOUT"},{"name":"top","displayName":"IMAGE_TOP_LAYOUT"}],"styles":[{"name":"Bold","class":"sample-component-bold-style"},{"name":"Italic","class":"sample-component-italic-style"}],"triggers":[{"triggerName":"imageClicked","triggerDescription":"Image clicked","triggerPayload":[{"name":"payloadData","displayName":"Trigger Payload Data"}]}],"actions":[{"actionName":"setImageWidth","actionDescription":"Update the image width","actionPayload":[{"name":"imageWidth","description":"Image Width in pixels","type":{"ojComponent":{"component":"ojInputText"}},"value":""}]}]}},"description":"","detailPageId":"","height":"","initialized":true,"isCaaSLayout":false,"linkType":"scs-link-action","marginBottom":5,"marginLeft":5,"marginRight":5,"marginTop":5,"nestedComponents":[{"id":"imageId","type":"scs-image","data":{"imageUrl":"[!--$SCS_DIST_FOLDER--]/renderer/app/sdk/images/sample-image.png","marginBottom":0,"marginLeft":0,"marginRight":20,"marginTop":0}},{"id":"titleId","type":"scs-title","data":{"userText":"<div>Local Component</div>","fontColor":"#000000","fontFamily":"'Helvetica Neue Light', Helvetica, Arial, sans-serif","fontSize":20,"marginBottom":14,"marginLeft":0,"marginRight":0,"marginTop":0,"useStyleClass":"false"}},{"id":"paragraphId","type":"scs-paragraph","data":{"userText":"<p style=\"line-height:1.4em;margin-bottom:4px;\">As a page author, you can edit the content and settings for this component. To change settings, including triggers and actions, click the component menu and choose Settings.</p><p style=\"line-height:1.4em;\">As a component developer, you can change the component and its defaults (such as this text) either by working with the files directly through the components browser or by using the desktop app to work with the files on your local system.</p>","fontColor":"#333333","fontFamily":"'Helvetica Neue Regular', Helvetica, Arial, sans-serif","fontSize":14,"marginBottom":10,"marginLeft":0,"marginRight":0,"marginTop":0,"useStyleClass":"false"}}],"renderOnAccess":"","styleClass":"","styleClassName":"","seeded":true,"useStyleClass":"true","visible":true,"visibleOnMobile":"","visibleNestedComponents":[],"width":0},"preRenderedByController":true},"a057a3dc-2397-4b35-88dc-e9904a3f1789":{"type":"scs-component","id":"scs-contentplaceholder","data":{"actions":"","alignment":"fill","assets":"","borderColor":"#808080","borderRadius":0,"borderStyle":"none","borderWidth":1,"componentId":"","componentName":"","componentFactory":"","componentLayout":"","contentId":"","contentLayoutCategory":"Blogs-Redwood-Next-Prev-Post","contentPlaceholder":true,"contentTypes":["Blog-Post","Syndicated-Blog-Post"],"contentTypeDisplayName":"","contentTypeCategory":"ContentType","contentViewing":"","customRenderComplete":false,"customSettingsData":"","componentConfig":"","description":"","detailPageId":"105","height":"","initialized":true,"isCaaSLayout":true,"linkType":"scs-link-action","marginBottom":5,"marginLeft":5,"marginRight":5,"marginTop":5,"nestedComponents":[],"renderOnAccess":"","styleClass":"","styleClassName":"","seeded":true,"useStyleClass":"true","visible":true,"visibleOnMobile":"","visibleNestedComponents":[],"width":0},"preRenderedByController":true}}},"navigationCurr":105}</script>
96 <script id="scsRenderObject" type="text/javascript">var require = {waitSeconds: 0};</script>
97
98
99
100 <script type="text/javascript">
101 window.SCSMacros = window.SCSMacros || {};
102 var url = window.location.href.split('?')[0];
103 var slug = url.substring(url.lastIndexOf('/') + 1);
104 //var slug = window.location.href.substring(window.location.href.lastIndexOf('/') + 1);
105 window.SCSMacros.getSlugMacro = slug;
106 </script>
107
108
109 <script type="text/javascript">
110 function expand() {
111 var x = document.getElementsByClassName("u03-collapsed");
112 var y = document.getElementsByClassName("u03-expanded");
113 for (var i = 0; i < x.length; i += 1) {
114 x[i].style.display = 'none';
115 }
116 for (var i = 0; i < y.length; i += 1) {
117 y[i].style.display = 'inline';
118 }
119 }
120
121 function collapse() {
122 var x = document.getElementsByClassName("u03-collapsed");
123 var y = document.getElementsByClassName("u03-expanded");
124 for (var i = 0; i < x.length; i += 1) {
125 x[i].style.display = 'inline';
126 }
127 for (var i = 0; i < y.length; i += 1) {
128 y[i].style.display = 'none';
129 }
130 }
131 </script>
132 <!--DTM/Launch embed code - Header -->
133
134
135 <script>!function(e){var n="https://s.go-mpulse.net/boomerang/";if("False"=="True")e.BOOMR_config=e.BOOMR_config||{},e.BOOMR_config.PageParams=e.BOOMR_config.PageParams||{},e.BOOMR_config.PageParams.pci=!0,n="https://s2.go-mpulse.net/boomerang/";if(window.BOOMR_API_key="G52AM-AGLAF-9JTSA-TBAP5-PCJJE",function(){function e(){if(!o){var e=document.createElement("script");e.id="boomr-scr-as",e.src=window.BOOMR.url,e.async=!0,i.parentNode.appendChild(e),o=!0}}function t(e){o=!0;var n,t,a,r,d=document,O=window;if(window.BOOMR.snippetMethod=e?"if":"i",t=function(e,n){var t=d.createElement("script");t.id=n||"boomr-if-as",t.src=window.BOOMR.url,BOOMR_lstart=(new Date).getTime(),e=e||d.body,e.appendChild(t)},!window.addEventListener&&window.attachEvent&&navigator.userAgent.match(/MSIE [67]\./))return window.BOOMR.snippetMethod="s",void t(i.parentNode,"boomr-async");a=document.createElement("IFRAME"),a.src="about:blank",a.title="",a.role="presentation",a.loading="eager",r=(a.frameElement||a).style,r.width=0,r.height=0,r.border=0,r.display="none",i.parentNode.appendChild(a);try{O=a.contentWindow,d=O.document.open()}catch(_){n=document.domain,a.src="javascript:var d=document.open();d.domain='"+n+"';void(0);",O=a.contentWindow,d=O.document.open()}if(n)d._boomrl=function(){this.domain=n,t()},d.write("<bo"+"dy onload='document._boomrl();'>");else if(O._boomrl=function(){t()},O.addEventListener)O.addEventListener("load",O._boomrl,!1);else if(O.attachEvent)O.attachEvent("onload",O._boomrl);d.close()}function a(e){window.BOOMR_onload=e&&e.timeStamp||(new Date).getTime()}if(!window.BOOMR||!window.BOOMR.version&&!window.BOOMR.snippetExecuted){window.BOOMR=window.BOOMR||{},window.BOOMR.snippetStart=(new Date).getTime(),window.BOOMR.snippetExecuted=!0,window.BOOMR.snippetVersion=12,window.BOOMR.url=n+"G52AM-AGLAF-9JTSA-TBAP5-PCJJE";var i=document.currentScript||document.getElementsByTagName("script")[0],o=!1,r=document.createElement("link");if(r.relList&&"function"==typeof r.relList.supports&&r.relList.supports("preload")&&"as"in r)window.BOOMR.snippetMethod="p",r.href=window.BOOMR.url,r.rel="preload",r.as="script",r.addEventListener("load",e),r.addEventListener("error",function(){t(!0)}),setTimeout(function(){if(!o)t(!0)},3e3),BOOMR_lstart=(new Date).getTime(),i.parentNode.appendChild(r);else t(!1);if(window.addEventListener)window.addEventListener("load",a,!1);else if(window.attachEvent)window.attachEvent("onload",a)}}(),"".length>0)if(e&&"performance"in e&&e.performance&&"function"==typeof e.performance.setResourceTimingBufferSize)e.performance.setResourceTimingBufferSize();!function(){if(BOOMR=e.BOOMR||{},BOOMR.plugins=BOOMR.plugins||{},!BOOMR.plugins.AK){var n=""=="true"?1:0,t="",a="jwstvjqx2o5kqziiqb3q-f-48999fc27-clientnsv4-s.akamaihd.net",i="false"=="true"?2:1,o={"ak.v":"36","ak.cp":"87563","ak.ai":parseInt("165106",10),"ak.ol":"0","ak.cr":11,"ak.ipv":4,"ak.proto":"h2","ak.rid":"208b9d63","ak.r":43514,"ak.a2":n,"ak.m":"dscx","ak.n":"essl","ak.bpcip":"77.165.58.0","ak.cport":51967,"ak.gh":"23.209.124.154","ak.quicv":"","ak.tlsv":"tls1.3","ak.0rtt":"","ak.csrc":"-","ak.acc":"","ak.t":"1695055991","ak.ak":"hOBiQwZUYzCg5VSAfCLimQ==vTvvCcS7yUvMFUwhArQjprHmS4SyRkG4kcqkubHf0SBAfLCipu8Z3GPJ9e1GyMuPUYO3XEA5R7RpN9uJTq4BkLQbssemRdXUWVprB4rKDAEYqcmRCULA0ABeQ3qfODyP2aGzM6krlmzdUN3sDRsfq+Nqtt/d3qfpf8l9Q/pZ/isYuJ22cZkbqcxVDrtC3ZfyKoGxC4nBvQYyr+3eRkNd8Mn4h1+thrx2qiKO5Edi+DH9ERMG1glOjsIjPS83+W6/oMyxNe216KPSO85XtLtxCjStIG+EsWHRDNn8MY7U1+NNOw66FTYI/LJSo1dChisD40fj1vqVfOoGWFXZRyiJ2eXHK16Azfupm2/vPIH7sRubbBznZp4fKYBBPzIHbMC7CN7dAPBdYhG7M0KpFWkrEWxSbdA9McNb2A+jwoaq3mo=","ak.pv":"262","ak.dpoabenc":"","ak.tf":i};if(""!==t)o["ak.ruds"]=t;var r={i:!1,av:function(n){var t="http.initiator";if(n&&(!n[t]||"spa_hard"===n[t]))o["ak.feo"]=void 0!==e.aFeoApplied?1:0,BOOMR.addVar(o)},rv:function(){var e=["ak.bpcip","ak.cport","ak.cr","ak.csrc","ak.gh","ak.ipv","ak.m","ak.n","ak.ol","ak.proto","ak.quicv","ak.tlsv","ak.0rtt","ak.r","ak.acc","ak.t","ak.tf"];BOOMR.removeVar(e)}};BOOMR.plugins.AK={akVars:o,akDNSPreFetchDomain:a,init:function(){if(!r.i){var e=BOOMR.subscribe;e("before_beacon",r.av,null,null),e("onbeacon",r.rv,null,null),r.i=!0}return this},is_complete:function(){return!0}}}}()}(window);</script></head>
136
137 <body class="f20 f20v1" style="opacity:0">
138 <script src="https://tms.oracle.com/main/prod/utag.sync.js"></script>
139
140 <!-- Loading script asynchronously -->
141 <script type="text/javascript">
142 (function (a, b, c, d) {
143 if (location.href.indexOf("tealium=dev") == -1) {
144 a = 'https://tms.oracle.com/main/prod/utag.js';
145 } else {
146 a = 'https://tms.oracle.com/main/dev/utag.js';
147 }
148 b = document; c = 'script'; d = b.createElement(c); d.src = a; d.type = 'text/java' + c; d.async = true;
149 a = b.getElementsByTagName(c)[0]; a.parentNode.insertBefore(d, a);
150 })();
151 </script>
152 <div class="f20w1">
153
154
155 <!-- U18v2 -->
156 <div class="u18 u18v2">
157
158 <div id="u18skip2content">
159 <ul>
160 <li><a id="u18skip2c" href="#maincontent">Skip to content</a></li>
161 <li><a id="u18acc" href="https://www.oracle.com/corporate/accessibility/">Accessibility Policy</a></li>
162 </ul>
163 </div>
164
165 <nav role="banner">
166 <div class="u18w1 cwidth">
167
168 <div class="u18w2">
169 <div class="u18-logo"><a href="https://blogs.oracle.com"><span>Oracle</span></a></div>
170 <div class="u18-title"><a href="" class="blog-name"></a></div>
171 </div>
172
173 <div class="u18w3">
174
175 <div class="u18-search">
176 <div class="u18-searchlink">
177 <a href="#search" aria-label="Open Search Field"><span>Search</span></a>
178 </div>
179 <div class="u18-searchform">
180 <a class="u18-search-action" id="u18exitsearch" href="#exitsearch"
181 aria-label="Exit Search Field"><span>Exit Search Field</span></a>
182 <div id="search" class="scs-slot" data-allowed-items="[ 'scs-contentsearch' ]">
183 </div>
184 <a class="u18-search-action" id="u18clearsearch" href="#clearsearch"
185 aria-label="Clear Search Field" tabindex="0"><span>Clear Search Field</span></a>
186 </div>
187 </div>
188 <div class="u18-langdd u18-dd">
189 <div class="u18-langselect u18-ddlink">
190 <a href="#select-language" aria-label="Select Language" role="button"><span
191 class="globe">Select Language</span></a>
192 </div>
193
194 <div class="u18-langoptions u18-menu">
195 <ul class="languagelist" id="languagelist">
196 <li><a href="#" class="u18v1w5v1"></a></li>
197 </ul>
198 </div>
199 </div>
200
201 <div class="u18-menudd u18-dd">
202 <div class="u18-hamburger u18-ddlink">
203 <a href="#menu" aria-label="Menu" aria-haspopup="true"
204 role="button"><span>Menu</span></a>
205 </div>
206 <div class="u18-menuoptions u18-menu" aria-hidden="true">
207 <div id="menu" class="slide-menu">
208 <!-- <ul class="ul.icn-list" id="u18-subview"> -->
209 <div id="blogs-category-nav" class="scs-slot"
210 data-allowed-items="[ 'Blogs-Redwood-Category-Nav' ]"><div class="scs-row"><div class="scs-col" style="width: 100%;"><div id="f62eb3cd-6ac8-407d-9e06-69cbbc8d821e"><div class="scs-component-bounding-box"><!-- -->
211 <div>
212 <div class="scs-custom-component scs-component sampleComp-default-style" style="margin-top:5px;margin-right:5px;margin-bottom:5px;margin-left:5px;">
213 <div class="scs-component-content" style="width:100%;">
214 <div style="" class="scs-custom-component-wrapper">
215 <div id="f62eb3cd-6ac8-407d-9e06-69cbbc8d821ecustomComponentDiv" data-scs-hydrate="true" data-asset-operation="view:CORE8B88E20204C04A0DADCEBC0499683C49">
216 <div class="blogs-nav">
217
218 <span class="h2-nav categories-text">CATEGORIES</span>
219 <ul class="ul.icn-list" id="u18-subview">
220
221
222
223 <li class="mainMenu hasNoMenu">
224 <a class="categ-menu" href="../category/lnx-announcements">Announcements</a>
225 </li>
226
227
228
229
230 <li class="mainMenu hasNoMenu">
231 <a class="categ-menu" href="../category/lnx-events">Events</a>
232 </li>
233
234
235
236
237 <li class="mainMenu hasNoMenu">
238 <a class="categ-menu" href="../category/lnx-oracle-cloud-infrastructure">Oracle Cloud Infrastructure</a>
239 </li>
240
241
242
243
244 <li class="mainMenu hasNoMenu">
245 <a class="categ-menu" href="../category/lnx-partners">Partners</a>
246 </li>
247
248
249
250
251 <li class="mainMenu hasNoMenu">
252 <a class="categ-menu" href="../category/lnx-perspectives">Perspectives</a>
253 </li>
254
255
256
257
258 <li class="mainMenu">
259 <a class="hasMenu active categ-menu" href="../category/lnx-ksplice">Technologies</a>
260 <div class="sub-categories">
261 <span class="back-btn" style="display: none;"><a href="javascript:void(0)">Back</a></span>
262
263 <ul style="margin: 0 !important">
264 <li>
265 <a href="../category/lnx-technologies">Technologies</a>
266 </li>
267 <li>
268 <a href="../category/lnx-ksplice">Ksplice</a>
269 </li>
270 <li>
271 <a href="../category/lnx-linux-kernel-development">Linux Kernel Development</a>
272 </li>
273 <li>
274 <a href="../category/lnx-linux-toolchain-and-tracing">Linux Toolchain & Tracing</a>
275 </li>
276 </ul>
277
278 </div>
279 </li>
280
281
282
283 <li class="mainMenu hasNoMenu">
284 <a class="categ-menu" href="../category/lnx-training">Training</a>
285 </li>
286
287
288 </ul>
289
290 <div class="u18-navdivider"></div>
291
292
293 <ul>
294 <li class="h2-nav related-content">RELATED CONTENT</li>
295 <div id="related-content">
296 <li><a href="#">Wim Coekaert's blog</a></li>
297 <li><a href="#">Hardware Cert. List</a></li>
298 <li><a href="#">ISV Catalog </a></li>
299 <li><a href="#">Validated Configs </a></li>
300 <li><a href="#">Developers</a></li>
301 <li><a href="#">GitHub</a></li>
302 <li><a href="#">Open Source</a></li>
303 </div>
304 </ul>
305 <div class="u18-navdivider"></div>
306 </div>
307
308
309 <div class="hydrated-container" data-hydrated="{"contentId":"CORE8B88E20204C04A0DADCEBC0499683C49","categories":["Announcements","Events","Oracle Cloud Infrastructure","Partners","Perspectives","Technologies","Training"],"compiledSite":true}"></div>
310 <!-- <script>
311
312 function showCategories() {
313 document.getElementsByClassName("categ-menu").classList.remove("categ-active");
314 document.getElementsByClassName("mainMenu").style.display = "";
315 document.getElementsByClassName("back-btn").classList.remove("show");
316 document.getElementsByClassName("categories-text").style.display = "";
317 document.getElementsByClassName("back-btn").style.display = "none";
318 document.getElementsByClassName("sub-categories").classList.remove("active");
319 document.getElementsByClassName("hasMenu").classList.add("active");
320 }
321
322 function showSubCategories(eventTarget) {
323 eventTarget.classList.add("categ-active");
324 document.getElementsByClassName("mainMenu").not(eventTarget).each(function () {
325 this.style.display = "none";
326 });
327 document.querySelectorAll('.sub-categories.active li:first-child a').focus();
328 document.getElementsByClassName("categories-text").style.display = "none";
329 document.getElementsByClassName("categ-active").next('.back-btn').classList.add("show");
330 eventTarget.parent('.mainMenu').style.display = "";
331 eventTarget.siblings('.sub-categories').classList.add("active");
332 eventTarget.classList.remove("active");
333 document.getElementsByClassName("back-btn").style.display = "";
334 document.querySelectorAll(".sub-categories.active li:last-child a").addEventListener('keydown', function (e) {
335 if (e.keyCode == 9) {
336 showCategories();
337 document.getElementsByClassName("hasMenu").classList.add("active");
338 }
339 });
340
341 }
342
343 document.on('click', '.hasMenu', function (e) {
344 e.preventDefault();
345 showSubCategories(this);
346 });
347 document.on('click', '.back-btn', function (e) {
348 showCategories();
349
350 });
351 document.getElementsByClassName("back-btn").keydown(function (e) {
352 if (e.keyCode == 9) {
353 showCategories();
354 $('.categ-menu.active').parent('.mainMenu').next('li').find('a').focus();
355 }
356 });
357
358 document.getElementsByClassName("hasMenu").keydown(function (e) {
359 if (e.keyCode == 9) {
360 showSubCategories(this);
361 }
362 });
363 document.getElementsByClassName("mainMenu").keydown(function (e) {
364 if (e.shiftKey && e.keyCode == 9) {
365 let hasMenuElement = this.prev('li').find('a').classList.contains("hasMenu");
366 if (hasMenuElement) {
367 e.preventDefault();
368 showSubCategories(this.prev('li').find('a.hasMenu'));
369 document.querySelectorAll(".sub-categories.active li:last-child a").focus();
370 }
371 }
372 })
373
374
375 let hydrateData = document.getElementsByClassName("hydrated-container")[0].getAttribute('data-hydrated');
376
377 if (hydrateData) {
378
379 var data = JSON.parse(hydrateData);
380 var postCategories = data.categories ? data.categories : [];
381 var metatags = document.getElementsByTagName("meta");
382 for (var i = 0; i < metatags.length; i++) {
383 if (metatags[i].name === "category" && postCategories.length !== 0) {
384 document.getElementsByTagName("meta")[i].content = postCategories.join();
385 }
386 if (metatags[i].name === "keywords" && postCategories.length !== 0) {
387 document.getElementsByTagName("meta")[i].content = postCategories.join();
388 }
389
390 }
391 }
392
393 </script> -->
394 </div>
395 </div>
396 </div>
397 </div>
398 </div>
399 </div></div></div></div></div>
400 <!-- </ul> -->
401 </div>
402
403 <ul>
404 <li><a href="" class="homepage">Blogs Home</a></li>
405 <li><a href="" class="blogdirectory">Blogs Directory</a></li>
406 <li><a href="" class="authordirectory">Featured Authors</a></li>
407
408 <li><a href="" class="rss-link">RSS</a></li>
409 </ul>
410 </div>
411
412 </div>
413
414 </div>
415
416 </div>
417 </nav>
418 <a id="maincontent"></a>
419 </div>
420 <!-- /U18v2 -->
421 <!-- RH03v5 -->
422 <section class="rh03 rh03v5 rw-ocean-150bg rw-pattern16w rw-pattern-15p rw-strip rw-strip-custom social">
423 <div class="rh03w1 cwidth social-wrapper">
424
425 <!-- <div class="rh03bc">
426
427
428 <div class="rh03bc">
429 <div class="rh03bc1">
430 <ol>
431 <li><a href="placeholder.html">Oracle blogs</a></li>
432 <li><a href="placeholder.html">Lorem ipsum dolor</a></li>
433 </ol>
434 </div>
435 </div>
436
437
438 </div> -->
439
440 <div class="rh03pgtitle">
441 <div class="blog-name"></div>
442 <div class="rh03subtitle">
443 <p></p>
444 </div>
445 <!-- <div id="bannerdescription"></div> -->
446 </div>
447 <div class="social-share-wrapper">
448 <label id="social-share">Follow: </label>
449 <ul class="social-share" aria-labelledby="social-share">
450 <li>
451 <a href="" title="Oracle blog RSS" class="icn-rss" target="_blank">
452 <span class="sr-only">RSS</span>
453 </a>
454 </li>
455 <li>
456 <a href="" title="Oracle blog on Facebook" class="icn-facebook" id="facebook-url" target="_blank">
457 <span class="sr-only">Facebook</span>
458 </a>
459 </li>
460 <li>
461 <a href="" title="Oracle blog on Twitter" class="icn-twitter" id="twitter-url" target="_blank">
462 <span class="sr-only">Twitter</span>
463 </a>
464 </li>
465 <li>
466 <a href="" title="Oracle blog on Linkedin" class="icn-linkedin" id="linkedin-url" target="_blank">
467 <span class="sr-only">LinkedIn</span>
468 </a>
469 </li>
470 <li>
471 <a href="" title="Oracle blog on Youtube" class="icn-youtube" id="youtube-url" target="_blank">
472 <span class="sr-only">Youtube</span>
473 </a>
474 </li>
475 <li>
476 <a href="" title="Oracle blog on Instagram" class="icn-instagram" id="instagram-url" target="_blank">
477 <span class="sr-only">Instagram</span>
478 </a>
479 </li>
480 </ul>
481 </div>
482
483 </div>
484 <div class="rh03customstrip" data-bgimg="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/img/rwstrip-blogs-fpo.png"></div>
485 </section>
486 <!-- /RH03v5 -->
487 <div class="scs-slot" id="post-id"><div class="scs-row"><div class="scs-col" style="width: 100%;"><div id="a37b49d5-e11f-4e1f-a5e0-fd37af71a288"><div class="scs-component-bounding-box"><!-- -->
488 <div>
489 <div class="scs-custom-component scs-component scs-component-default-style" style="margin-top:5px;margin-right:5px;margin-bottom:5px;margin-left:5px;">
490 <div class="scs-component-content" style="width:100%;">
491 <div style="" class="scs-custom-component-wrapper">
492 <div id="a37b49d5-e11f-4e1f-a5e0-fd37af71a288customComponentDiv" data-scs-hydrate="true" data-scs-contenttype="Blog-Post" data-asset-operation="view:CORE8B88E20204C04A0DADCEBC0499683C49">
493 <style>
494 .title {
495 background-color: #fff;
496 border: 1px solid #F1EFED;
497 border-radius: 22px;
498 max-width: 940px;
499 margin: 0 auto;
500 padding: 5px 25px;
501 }
502 </style>
503 <!-- RC81v1 -->
504
505 <section class="rc81 rc81v1 cpad">
506
507 <div class="rc81w1 bwidth">
508
509 <div class="rc81">
510 <ul>
511 <li class="post-categories"><a href="../category/lnx-technologies" class="rc81accent"> Technologies<span>, </span> </a></li>
512 <li class="post-categories"><a href="../category/lnx-linux-kernel-development" class="rc81accent"> Linux Kernel Development<span>, </span> </a></li>
513 </ul>
514
515 </div>
516 <p class="rc81accent" id="categories"></p>
517 <h1>Syscall latency... and some uses of speculative execution</h1>
518 <span id="publishdate">September 12, 2023 |</span><span id="publishdate"> 23 minute read</span>
519
520 <div class="rc81sub ">
521 <img src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/img/ui_defaultuserimage.jpg" alt="">
522
523 <span><a id="postAuthorName" href="/authors/ankur-arora">Ankur Arora</a>
524 <div><span class="rc81title rw-neutral-200txt"></span>
525
526 </div>
527 </span></div>
528
529
530 <!--
531 <div class="rc81photo">
532 <img src="">
533 </div>
534 -->
535
536 </div>
537 </section>
538 <!-- /RC81v1 --><!-- RC82v0 -->
539 <!-- /RC82v0 --><!-- RC86v0 -->
540 <section class="rc86 rc86v0 cpad">
541 <div class="rc86w1 bwidth">
542 <div class="rc86social">
543 <a href="https://www.facebook.com/dialog/share?app_id=209650819625026&href=../post/syscall-latency" class="sharelink icn-img icn-facebook" aria-label="Share post on Facebook" data-sharetype="facebook">
544 <!-- <span>Facebook</span> -->
545 </a>
546 <a href="https://twitter.com/share?url=../post/syscall-latency" class="sharelink icn-img icn-twitter" aria-label="Share post on Twitter" data-sharetype="twitter">
547 <!-- <span>Twitter</span> -->
548 </a>
549 <a href="https://www.linkedin.com/shareArticle?url=../post/syscall-latency" aria-label="Share post on Linkedin" class="sharelink icn-img icn-linkedin" data-sharetype="linked-in">
550 <!-- <span>LinkedIn</span> -->
551 </a>
552 <a href="placeholder.html" class="sharelink icn-img icn-email" aria-label="Share post on Email" data-sharetype="email">
553 <!-- <span>Email</span> -->
554 </a>
555 </div>
556 </div>
557 </section>
558 <!-- /RC86v0 -->
559
560 <!-- RC84v0 -->
561 <section class="rc84v0 rc84zoom ">
562 <div class="rc84w1 bwidth">
563 <div class="rc84zoomui">
564 <b>Text Size <span id="rc84fs">100%</span>:</b>
565 <div>
566 <a href="#smaller-text" class="rc84-smaller" aria-label="decrease font size to 90%">－</a>
567 <a href="#larger-text" class="rc84-larger" aria-label="increase font size to 110%">＋</a>
568 </div>
569 </div>
570
571
572 <div class="rc84post">
573
574 <!-- RC84v1 -->
575 <section class="rc84 rc84v1">
576
577 <h2 id="introduction">Introduction</h2>
578
579 <p>Moving from UEK5 to UEK6 brought about an unwelcome surprise: an increase in syscall latency on some x86 systems. The root cause, as we will see, was slightly slower evaluation of audit rules, which, given that they are evaluated for every syscall, is not great.</p>
580
581 <p>In this post we start off by exploring the root cause which turns out to not be UEK specific, it also impacts upstream kernels as well. Then we detail the fixes and how they take advantage of the speculative out-of-order nature of the CPU pipeline.</p>
582
583 <p>The changes, even though they target low-level optimizations, are quite straight-forward, almost trivial.</p>
584
585 <h3 id="background">Background</h3>
586
587 <p>Execution latency of the <code style="background:#eeeeee;border:1px solic #cccccc;">getpid()</code>[1] increased by about 15% (measured on an Intel Skylake-X system), from 191ns on UEK5, to 217ns on UEK6.</p>
588
589 <p>This was measured in the usual way:</p>
590
591 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">clock_gettime(CLOCK_MONOTONIC, &start);
592 for (i = 0; i < large_number; i++)
593 syscall(SYS_getpid);
594 clock_gettime(CLOCK_MONOTONIC, &stop);</pre>
595
596 <p>A quick <code style="background:#eeeeee;border:1px solic #cccccc;">perf record</code>, showed that almost all of the increased latency was in <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code> which was more expensive in UEK6.</p>
597
598 <p>Oracle Exadata, where this problem was seen has 37 audit rules that are evaluated in the syscall path. Since audit only wants to log unusual or exceptional events, the benchmark would evaluate these rules in every iteration, but never generate any output. Essentially, purely local computation that became slower without there having been any material changes to the audit code or in the audit rules.</p>
599
600 <h3 id="cpu-parameters">CPU-parameters</h3>
601
602 <p>Some Intel Skylake-X parameters that we'll make use of later:</p>
603
604 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">L1-load-latency: 4-6 cycles
605 L2-load-latency: 14 cycles
606 L1-cache-size: 32K (512 cachelines: 64 sets, 8 ways each)
607
608 ROB size: 224 micro-ops</pre>
609
610 <p>The parameters are taken from the <a href="https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html">Intel SDM</a>.</p>
611
612 <p><strong>Note:</strong> L1/L2 being the respective data-cache level and ROB, being the Reorder Buffer, where instructions are staged for in-order retirement.</p>
613
614 <h2 id="root-cause-analysis">Root cause analysis</h2>
615
616 <p>Drilling down with <code style="background:#eeeeee;border:1px solic #cccccc;">perf stat -d</code>:</p>
617
618 <p>UEK5 (191 ns):</p>
619
620 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"># perf stat -d -r 5 ./getpid
621 # output normalized for a single getpid() call
622
623 677.9 cycles # 3.542 GHz
624 1635.0 instructions # 2.40 insn per cycle
625 325.0 branches
626 0.5 branch-misses # 0.16% of all branches
627 404.0 L1-dcache-loads
628 0.4 L1-dcache-load-misses # 0.10% of all L1-dcache accesses</pre>
629
630 <p>UEK6 (217ns):</p>
631
632 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"># perf stat -d -r 5 ./getpid
633 # output normalized for a single getpid() call
634
635 770.4 cycles # 3.545 GHz
636 1652.0 instructions # 2.14 insn per cycle
637 332.2 branches
638 1.5 branch-misses # 0.45% of all branches
639 407.3 L1-dcache-loads
640 8.6 L1-dcache-load-misses # 2.13% of all L1-dcache accesses</pre>
641
642 <p>Comparing, this is an increase of ~100 cycles with the L1d-loads and instruction counts being almost identical across UEK5 and UEK6. This underscores the fact that audit code which forms the bulk of instructions executed hasn’t changed all that much.</p>
643
644 <p>The IPC is commensurately lower[2]. The proximal cause seems to be the increased L1d-load-misses and the one extra branch-miss.</p>
645
646 <p>These observations were confirmed via enough non-correlated runs (with intervening reboot for each) and so are statistically significant. The L1d-load-miss numbers are somewhat variable across boot cycles, but the trend is close to what we see above.</p>
647
648 <h3 id="audit_filter_syscall"><code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code></h3>
649
650 <p>From <code style="background:#eeeeee;border:1px solic #cccccc;">perf record</code> we know that the bulk of the increased runtime went to <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code>. The procedure itself is primarily a loop that walks the list of rules, calling <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code> for each rule to check if it needs to be evaluated for the current syscall. For <code style="background:#eeeeee;border:1px solic #cccccc;">getpid()</code> the answer will be <code style="background:#eeeeee;border:1px solic #cccccc;">false</code> most of the time (32 of 37 times.)</p>
651
652 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">audit_filter_syscall(...) {
653 struct audit_entry *e;
654 struct audit_entry *ctx;
655
656 list = audit_filter_list[AUDIT_FILTER_EXIT];
657
658 list_for_each_entry_rcu(e, list, list) {
659
660 if (audit_in_mask(&e->rule, ctx->major) &&
661 audit_filter_rules(tsk, &e->rule, ctx, NULL,
662 &state, false, x)) {
663 rcu_read_unlock();
664 ctx->current_state = state;
665 return state;
666 }
667 }
668
669
670 }
671
672 audit_in_mask(const struct audit_krule *rule, unsigned long val) {
673 if (val > 0xffffffff)
674 return false;
675
676 /*
677 * val contains the current syscall number. AUDIT_WORD does
678 * some bit shifting on it.
679 */
680 word = AUDIT_WORD(val);
681 if (word >= AUDIT_BITMASK_SIZE)
682 return false;
683
684 bit = AUDIT_BIT(val);
685
686 /*
687 * The load in rule->mask[word] depends on the audit_krule (which
688 * hangs off the current rule entry) and the syscall number.
689 */
690 return rule->mask[word] & bit;
691 }
692 audit_filter_rules(...) {
693 /*
694 * Large switch statement which we ignore for the rest of this
695 * analysis because, as we will see later, loads executed in it don't
696 * have an "interesting" alignment and so their latency should be easy
697 * enough to hide.
698 */
699 }</pre>
700
701 <h3 id="memory-accesses">Memory accesses</h3>
702
703 <p>Next let’s look at the data structures accessed in the <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code> loop and where the L1d-load-misses might be coming from.</p>
704
705 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">/* Data structure layout annotated with size and cacheline occupancy
706 * information using pahole. */
707
708 struct audit_entry { /* via audit_filter_list[AUDIT_FILTER_EXIT] */
709
710 struct list_head list; /* 0 16 */
711 struct callback_head rcu; /* 16 16 */
712 struct audit_krule rule; /* 32 376 */
713 ...
714 /* size: 408, cachelines: 7, members: 3 */
715 /* last cacheline: 24 bytes */
716 };
717
718 struct audit_krule { /* inlined in struct audit_entry */
719 ...
720 u32 mask[64]; /* 16 256 */
721 ...
722 /* size: 376, cachelines: 6, members: 17 */
723 /* last cacheline: 56 bytes */
724 };
725
726 struct audit_context {
727 ...
728 int major; /* 20 4 */
729 ...
730 /* size: 920, cachelines: 15, members: 46 (slightly larger on UEK6) */
731 /* sum members: 912, holes: 2, sum holes: 8 */
732 /* last cacheline: 24 bytes */
733 };</pre>
734
735 <p>The effective execution loop in <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code> (with cacheline access annotations):</p>
736
737 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">struct audit_entry *e = &audit_filter_list[AUDIT_FILTER_EXIT];
738
739 for_each_iteration {
740 e = e->next; /* cacheline-0 of audit_entry */
741 if (e == list)
742 jmp out;
743 if (audit_in_mask(e->rule.mask, /* cacheline-0 of audit_entry */
744 ctx->major)) /* cacheline-0 of audit_context */
745 audit_filter_rules(e->rule);
746 }
747 out:</pre>
748
749 <p>As the annotations above mention, there are a total of three loads:</p>
750
751 <ol type="1">
752 <li>Pointer chasing in <code style="background:#eeeeee;border:1px solic #cccccc;">e->next</code>: the first cacheline of <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_entry</code>.</li>
753 <li><code style="background:#eeeeee;border:1px solic #cccccc;">e->rule.mask[]</code>: accesses the same cacheline as load (1) above.</li>
754 <li><code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code>: accesses the first cacheline of <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_context</code>.</li>
755 </ol>
756
757 <p>Loads (1) and (2) will access a total of 37 cachelines, corresponding to a rule per iteration. Also notice that every single basic block in the rest of the iteration (apart from some error checking in <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code>) has data dependence on the evaluation of <code style="background:#eeeeee;border:1px solic #cccccc;">e=e->next</code>. Worse this is a loop carried dependency, so each iteration depends on the previous one.</p>
758
759 <p>The cacheline for load (3) is accessed once every iteration. This load is unnecessary, <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> contains the syscall number, which is a constant for the duration of the syscall. However, because the compiler’s alias analysis cannot prove that <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> is not mutilated, it does not get cached in a register. This also means that <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code> will do out-of-bound validation checks related to <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> over and over.</p>
760
761 <p>Recalling the <code style="background:#eeeeee;border:1px solic #cccccc;">perf-stat -d</code> output above there are a total of around 400 L1d-loads for each <code style="background:#eeeeee;border:1px solic #cccccc;">getpid()</code> call. Of those, the loop does a total of 37*3 loads which map to a total of 38 unique cachelines.</p>
762
763 <p>Alright, I hear you think: granted, walking linked-lists is difficult, there are a lot of cachelines in a lot of iterations or whatever, life is hard and the compiler doesn’t know what it is doing[3]. Even given all of that, nothing here has changed from UEK5 to UEK6, so none of this explains why UEK6 would incur more L1d-load-misses[4].</p>
764
765 <p>Which is true, so that’s next.</p>
766
767 <h3 id="theory-of-the-case">Theory of the case</h3>
768
769 <p>From the background above, we know that the loop is pure computation, and purely local computation at that, so code changes elsewhere should have no effect. And there were no significant code changes from UEK5 to UEK6, so the loop is unchanged (which also applies to the generated assembly.)</p>
770
771 <p>Now insofar as L1d-load-misses are concerned: the number of cachelines accessed (from about 400 L1d-loads per <code style="background:#eeeeee;border:1px solic #cccccc;">getpid()</code> call, not all of which are to unique cachelines) amount to a number comfortably below the Skylake-X L1d-cache capacity of 512 cachelines. So this loop should not incur any capacity misses.</p>
772
773 <p>Which leaves conflict misses as the probable cause[5]. Skylake-X has an 8-way associative L1: if more than 8 loads in the loop map to the same cache-set some accesses would incur conflict misses.</p>
774
775 <p>Accesses in the loop and how they map to cache-sets:</p>
776
777 <ul>
778 <li><code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_entry</code>: aligns at a 512B boundary, which limits it to cache-sets <code style="background:#eeeeee;border:1px solic #cccccc;">{0, 8, 16, ... 56}</code>, for a total of 8*8 cache-slots.</li>
779 <li><code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_context</code>: aligns at a 1024B boundary, which resolves to cache-sets <code style="background:#eeeeee;border:1px solic #cccccc;">{0, 16, 32, 48}</code>, for a total of 4*8 cache-slots. As described earlier, this is a single cacheline which competes with a subset of the <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_entry</code> cachelines.</li>
780 </ul>
781
782 <p>Even then, this is 37 cachelines slotted into 64 slots and another slotting into 32 of those 64. This should be easy enough to satisfy, assuming that the kernel allocator has a reasonably sane distribution and isn’t skewed towards a particular set of cachelines (or is similarly skewed on both UEK5 and UEK6.)</p>
783
784 <h3 id="allocation-skew">Allocation skew</h3>
785
786 <p>If, allocations for <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_entry</code> were distributed uniformly, they would map into cache-sets uniformly, ending with similar populations across the cache-sets. This would give a cacheline-spread metric of ~0 (obtained by calculating the standard-deviation of populations across cache-sets.)</p>
787
788 <p>What we see:</p>
789
790 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">cacheline-spread on UEK5: 1.58
791 cacheline-spread on UEK6: 1.91</pre>
792
793 <p>(These results are from a large number (> 100) of non-correlated runs. <code style="background:#eeeeee;border:1px solic #cccccc;">auditd</code> allocates at boot, so this was done by rebooting between each run.)</p>
794
795 <p>From these numbers, UEK5 is far from a flat distribution, and UEK6 is somewhat worse, but not dispositively so. Additionally, a slight imbalance will not cause performance degradation: that happens only after cache conflicts kick in, which is after cache-set population crosses the associativity threshold.</p>
796
797 <p>To validate this, we measure how well cycles correlate[6] with 1) with L1d-misses, and 2) cacheline-spread:</p>
798 <style type="text/css">.divTable {
799 display: table;
800 width: 80%;
801 }
802 .divTableRow {
803 display: table-row;
804 }
805 .divTableHeading {
806 display: table-header-group;
807 background-color: #ddd;
808 font-weight: bold;
809 }
810 .divTableCell {
811 display: table-cell;
812 padding: 3px 10px;
813 border: 1px solid #999999;
814 }
815 </style>
816 <p> </p>
817
818 <div class="divTable">
819 <div class="divTableHeading">
820 <div class="divTableCell">Kernel</div>
821
822 <div class="divTableCell">cycles:L1d-misses</div>
823
824 <div class="divTableCell">cycles:cacheline-spread</div>
825 </div>
826
827 <div class="divTableRow">
828 <div class="divTableCell">UEK5</div>
829
830 <div class="divTableCell">0.74</div>
831
832 <div class="divTableCell">0.22</div>
833 </div>
834
835 <div class="divTableRow">
836 <div class="divTableCell">UEK6</div>
837
838 <div class="divTableCell">0.74</div>
839
840 <div class="divTableCell">0.61</div>
841 </div>
842 </div>
843
844 <p> </p>
845
846 <p>For both UEK5 and UEK6, “cycles:L1d-misses” is tightly correlated (though the value of 0.74 for both is happenstance) which makes sense. “cycles:cacheline-spread”, however, is well correlated only on UEK6, not UEK5. This suggests that the UEK6 allocator skew is meaningfully worse, enough to cause lower performance.</p>
847
848 <p>Alright, having beaten this dead horse enough, let’s figure out how to fix it next[7].</p>
849
850 <h2 id="speeding-it-up">Speeding it up</h2>
851
852 <p>To get back our lost performance, our task is simple: optimize a hot-loop[8] which is itself executed in the hot syscall path. Compounding the problem, the critical load in the loop is accessed via a linked list.</p>
853
854 <p>Stated like that, it sounds pretty bad. But, as we will see the structure of the problem helps quite a bit:</p>
855
856 <ol type="1">
857 <li>On a sane system, the common-case is extremely common, syscalls are frequent, and audit logging is unusual. This means that low branch mispreds are not unusual and something we might even depend on.</li>
858 <li>We are optimizing a no-op loop: the loop walks a bunch of rules, does error checking, and decides if it needs to log. In the common-case, it will conclude that it doesn’t. (This is really (1) restated to stress the no-op nature of the loop.)</li>
859 </ol>
860
861 <p>A no-op loop implies that the code does not actually care about most of the values it computes. It just inches towards a foregone conclusion.</p>
862
863 <p>This it does (as all code does) by means of dependency chains that transform the input state to output. Here, most dependency chains are short and, are really <em>only used to predict the control flow</em>. The only long dependency chain, woven through all the loop iterations, is the one walking the linked-list.</p>
864
865 <p>Now, critically since the branches are predicted perfectly or almost so, the control flow can run quite a bit further than any loads and dependent computation. The control flow thus essentially feeds these loads and other instructions to the ROB, where they wait until resources/dependencies become available, compute the output from their chain which, to reiterate, will only be used to predict the control flow.</p>
866
867 <p>Given that the control flow is already feeding instructions from the correct direction, these are in effect orphan chains that eventually retire without anyone having cared for the output they compute or how long that took.</p>
868
869 <p>Except: this happy state continues only until we run into a resource constraint. For instance, the size of the ROB on Skylake-X is 224 entries and each loop iteration is ~20 instructions. This means instructions worth around 10 loop iterations can be present in the ROB. Now, given that instructions retire on x86 in-order, long running instructions (L1d-load-misses of course, but also L1d-load hits[9]) with long dependence chains would slow retirement down, even were control-flow to be predicted perfectly.</p>
870
871 <p>Bearing these observations in mind, our fixes will try to reduce the amount and cost of work per loop iteration. This allows the loop to retire as close to the gating latency of any long running instructions in the loop.</p>
872
873 <h3 id="cache-ctx-major-in-audit_filter_syscall">Cache <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> in <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code></h3>
874
875 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">@@ -785,13 +785,14 @@ static enum audit_state audit_filter_syscall(struct task_struct *tsk,
876 {
877 struct audit_entry *e;
878 enum audit_state state;
879 + unsigned long major = ctx->major;
880
881 if (auditd_test_task(tsk))
882 return AUDIT_DISABLED;
883
884 rcu_read_lock();
885 list_for_each_entry_rcu(e, list, list) {
886 - if (audit_in_mask(&e->rule, ctx->major) &&
887 + if (audit_in_mask(&e->rule, major) &&
888 audit_filter_rules(tsk, &e->rule, ctx, NULL,
889 &state, false)) {
890 rcu_read_unlock();</pre>
891
892 <p>Caching <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> in a local variable helps in two ways:</p>
893
894 <ul>
895 <li>Explicitly indicates to the compiler that there are no stores to the cached value. <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code> operates on <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> doing some bit-shifting and error checking. Now that the compiler knows that <code style="background:#eeeeee;border:1px solic #cccccc;">major</code> is not modified, it can hoist most of that logic out of the loop so it is not reevaluated over-and-over in every loop iteration.</li>
896 <li>As described earlier, <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_context</code> has similar natural alignment concerns as <code style="background:#eeeeee;border:1px solic #cccccc;">struct audit_entry</code>. Allowing the compiler to cache <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code> in a register (or on the stack) reduces one potential source of contention.</li>
897 </ul>
898
899 <p>With this change the number of instructions executed/loop-iteration reduce by 8 (of 20.) Note that most of those were almost free ALU instructions.</p>
900
901 <p>L1d-loads: we removed one L1d-load but added two (due to the compiler now spilling and reloading some state to/from the stack.) However, given that stack accesses are much less likely to have conflicting alignment constraints, the increased loads are less of a concern than the one we got rid of.</p>
902
903 <p>cycles: improve by about 40 cycles. This is because the greater room in the ROB allows our almost perfect branch prediction to speculatively run even further ahead of other instructions.</p>
904
905 <p>Change in latency for UEK6:</p>
906
907 <div class="divTable">
908 <div class="divTableHeading">
909 <div class="divTableCell">Version</div>
910
911 <div class="divTableCell">Min<br>
912 (ns)</div>
913
914 <div class="divTableCell">Mean<br>
915 (ns)</div>
916
917 <div class="divTableCell">Median<br>
918 (ns)</div>
919
920 <div class="divTableCell">Max<br>
921 (ns)</div>
922 </div>
923
924 <div class="divTableRow">
925 <div class="divTableCell">baseline</div>
926
927 <div class="divTableCell">196.26</div>
928
929 <div class="divTableCell">212.00</div>
930
931 <div class="divTableCell">207.80</div>
932
933 <div class="divTableCell">240.52</div>
934 </div>
935
936 <div class="divTableRow">
937 <div class="divTableCell">ctx->major</div>
938
939 <div class="divTableCell">183.50</div>
940
941 <div class="divTableCell">201.41</div>
942
943 <div class="divTableCell">198.80</div>
944
945 <div class="divTableCell">226.93</div>
946 </div>
947 </div>
948
949 <p> </p>
950
951 <p>From the min-max range, there is a rather large variation in latency that’s caused by variations in allocation resulting in high or low cacheline-spread. In almost all cases though, the latency improves by ~10ns or thereabouts.</p>
952
953 <p>That said, after removing 8 instructions and one load (and adding two less consequential loads), the performance gain is rather miniscule: ~1 cycle/iteration. Just that the loop executes 37 times, so we make it up in volume.</p>
954
955 <p>More details (<code style="background:#eeeeee;border:1px solic #cccccc;">perf-stat</code> and the before/after versions of the generated code) in <a href="https://github.com/oracle/linux-uek/commit/87a39a3d2ca9a5c7e4d35e4cf4b839c53cc0678d">UEK6 commit-1</a> and in <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/auditsc.c?id=069545997510833281f45f83e097017b9fef19b7">Upstream commit-1</a>.</p>
956
957 <h3 id="annotate-branch-direction-for-audit_in_mask">Annotate branch direction for <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code></h3>
958
959 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">@@ -790,12 +790,13 @@ static enum audit_state audit_filter_syscall(struct task_struct *tsk,
960 rcu_read_lock();
961 list_for_each_entry_rcu(e, list, list) {
962 - if (audit_in_mask(&e->rule, major) &&
963 - audit_filter_rules(tsk, &e->rule, ctx, NULL,
964 - &state, false)) {
965 ...
966 + if (unlikely(audit_in_mask(&e->rule, major))) {
967 + if (audit_filter_rules(tsk, &e->rule, ctx, NULL,
968 + &state, false)) {</pre>
969
970 <p>Annotate <code style="background:#eeeeee;border:1px solic #cccccc;">audit_in_mask()</code> as <code style="background:#eeeeee;border:1px solic #cccccc;">unlikely()</code> to allow the compiler to pessimize the call to <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_rules()</code>. Two reasons for this change:</p>
971
972 <ul>
973 <li>The primary motivation was to get rid of the extra branch mispred. This change succeeds in that task but it is unclear why: there’s no significant change in the basic-block structure. The only change is from a branch inversion due to the unlikely clause.</li>
974 <li>The branch inversion means that the not-taken direction is chosen more often: 32/37 times (changing from 5/37 earlier.) The issue-latency for not-taken branches is 0.5-1 cycles, for taken branches 1-2 cycles[10] is slightly cheaper.</li>
975 </ul>
976
977 <p>L1d-loads: reduce by 2 for each loop iteration. This is because the spills and reloads introduced in the “Cache <code style="background:#eeeeee;border:1px solic #cccccc;">ctx->major</code>…” patch have now been shifted to the unlikely path (the prologue and epilogue of the <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_rules()</code> call.)</p>
978
979 <p>cycles: performance improves on average by ~30 cycles/call.</p>
980
981 <p>Change in latency for UEK6:</p>
982
983 <div class="divTable">
984 <div class="divTableHeading">
985 <div class="divTableCell">Version</div>
986
987 <div class="divTableCell">Min<br>
988 (ns)</div>
989
990 <div class="divTableCell">Mean<br>
991 (ns)</div>
992
993 <div class="divTableCell">Median<br>
994 (ns)</div>
995
996 <div class="divTableCell">Max<br>
997 (ns)</div>
998 </div>
999
1000 <div class="divTableRow">
1001 <div class="divTableCell">ctx->major</div>
1002
1003 <div class="divTableCell">183.50</div>
1004
1005 <div class="divTableCell">201.41</div>
1006
1007 <div class="divTableCell">198.80</div>
1008
1009 <div class="divTableCell">226.93</div>
1010 </div>
1011
1012 <div class="divTableRow">
1013 <div class="divTableCell">ctx->major+annot</div>
1014
1015 <div class="divTableCell">165.26</div>
1016
1017 <div class="divTableCell">188.72</div>
1018
1019 <div class="divTableCell">184.25</div>
1020
1021 <div class="divTableCell">230.34</div>
1022 </div>
1023 </div>
1024
1025 <p> </p>
1026
1027 <p>More details (<code style="background:#eeeeee;border:1px solic #cccccc;">perf-stat</code> and the before/after versions of the generated code) in <a href="https://github.com/oracle/linux-uek/commit/0288dbdbfb5768ad8ae8a445c72f523bcb99eca0">UEK6 commit-2</a>.</p>
1028
1029 <h3 id="remove-static-linkage-from-audit_filter_syscall">Remove static linkage from <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code></h3>
1030
1031 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">@@ -777,7 +777,7 @@ static bool audit_in_mask(const struct audit_krule *rule, unsigned long
1032 * also not high enough that we already know we have to write an audit
1033 * record (i.e., the state is AUDIT_SETUP_CONTEXT or AUDIT_BUILD_CONTEXT).
1034 */
1035 -static enum audit_state audit_filter_syscall(struct task_struct *tsk,
1036 +enum audit_state audit_filter_syscall(struct task_struct *tsk,
1037 struct audit_context *ctx,
1038 struct list_head *list)</pre>
1039
1040 <p><code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code> is only used locally in the file and so is marked <code style="background:#eeeeee;border:1px solic #cccccc;">static</code>. Additionally, it’s only ever called with a fixed <code style="background:#eeeeee;border:1px solic #cccccc;">list</code> value of <code style="background:#eeeeee;border:1px solic #cccccc;">&audit_filter_list[AUDIT_FILTER_EXIT])</code>.</p>
1041
1042 <p>GCC’s constant propagation pass makes use of these two things to, quite reasonably, const-propagate the third argument to the point of use.</p>
1043
1044 <p>This causes the exit check in the <code style="background:#eeeeee;border:1px solic #cccccc;">list_for_each</code> loop to look like this:</p>
1045
1046 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">audit_filter_syscall.constprop.18(task, ctx):
1047 0: 48 8b 1b mov (%rbx),%rbx
1048 3: 48 81 fb e0 67 ac 82 cmp $0xffffffff82ac67e0,%rbx
1049 ffffffff8118b5ed: R_X86_64_32S audit_filter_list+0x40
1050 10: 75 e2 jne start_iter</pre>
1051
1052 <p>while, without const-propagation it would have looked like this:</p>
1053
1054 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">audit_filter_syscall(task, ctx, list):
1055 0: 48 8b 1b mov (%rbx),%rbx
1056 3: 4c 39 e3 cmp %r12,%rbx
1057 6: 75 e6 jne start_iter</pre>
1058
1059 <p>Now either one ought to be alright, both <code style="background:#eeeeee;border:1px solic #cccccc;">cmp imm32,r</code> and <code style="background:#eeeeee;border:1px solic #cccccc;">cmp r,r</code> forms are equivalent with a latency of 1 cycle, and both are a single micro-op each.</p>
1060
1061 <p>The second form of the <code style="background:#eeeeee;border:1px solic #cccccc;">cmp</code>, however, can be macro-op fused with the <code style="background:#eeeeee;border:1px solic #cccccc;">jne</code>; not entirely sure if the first form can be[11]. The second form is also denser, though that’s not a concern here.</p>
1062
1063 <p>Disallowing GCC from making assumptions about calling contexts by removing the <code style="background:#eeeeee;border:1px solic #cccccc;">static</code> linkage from <code style="background:#eeeeee;border:1px solic #cccccc;">audit_filter_syscall()</code> forces it to pass the <code style="background:#eeeeee;border:1px solic #cccccc;">list</code> parameter in a register which results in a small performance improvement: ~20 cycles (about 0.5 cycles/loop iteration.)</p>
1064
1065 <p>Change in latency for UEK6:</p>
1066
1067 <div class="divTable">
1068 <div class="divTableHeading">
1069 <div class="divTableCell">Version</div>
1070
1071 <div class="divTableCell">Min<br>
1072 (ns)</div>
1073
1074 <div class="divTableCell">Mean<br>
1075 (ns)</div>
1076
1077 <div class="divTableCell">Median<br>
1078 (ns)</div>
1079
1080 <div class="divTableCell">Max<br>
1081 (ns)</div>
1082 </div>
1083
1084 <div class="divTableRow">
1085 <div class="divTableCell">ctx->major+annot</div>
1086
1087 <div class="divTableCell">165.26</div>
1088
1089 <div class="divTableCell">188.72</div>
1090
1091 <div class="divTableCell">184.25</div>
1092
1093 <div class="divTableCell">230.34</div>
1094 </div>
1095
1096 <div class="divTableRow">
1097 <div class="divTableCell">ctx->major+annot+extern</div>
1098
1099 <div class="divTableCell">159.88</div>
1100
1101 <div class="divTableCell">184.35</div>
1102
1103 <div class="divTableCell">177.62</div>
1104
1105 <div class="divTableCell">250.82</div>
1106 </div>
1107 </div>
1108
1109 <p> </p>
1110
1111 <p>More details (<code style="background:#eeeeee;border:1px solic #cccccc;">perf-stat</code> and the before/after versions of the generated code) in <a href="https://github.com/oracle/linux-uek/commit/5a74015e20bff63d1052359fbc2c3418e0f6bc4e">UEK6 commit-3</a> and, <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/auditsc.c?id=50979953c0c41e929e5f955800da68e1bb24c7ab">Upstream commit-3</a>.</p>
1112
1113 <h2 id="summary">Summary</h2>
1114
1115 <p>The audit subystem is fairly stable in the Linux kernel, not given to frequent changes. So it was puzzling when it became slower in recent kernels, and because a primary user is the syscall path, concerning[12].</p>
1116
1117 <p>The cause turned out to be higher skew in allocated buffers which results in more lopsided cache-set distribution.</p>
1118
1119 <p>The fixes compensate for the higher costs in the loop by taking advantage of the peculiarities of the execution path and optimizing for the speculative nature of the CPU pipeline.</p>
1120
1121 <p>The three patches, in sum reduce the overhead by about 30ns (~100 cycles).</p>
1122
1123 <p>Final <code style="background:#eeeeee;border:1px solic #cccccc;">perf stat -d -r 5</code> go from:</p>
1124
1125 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"># perf stat -d -r 5 ./getpid
1126 # output normalized for a single getpid() call
1127
1128 cycles 761.65 ( +- 5.22% )
1129 instructions 1639.17 ( +- 0.00% )
1130 IPC 2.18 ( +- 5.50% )
1131 branches 328.21 ( +- 0.00% )
1132 branch-misses 1.37 ( +- 6.56% )
1133 L1-dcache-loads 404.35 ( +- 0.00% )
1134 L1-dcache-load-misses 7.99 ( +- 70.71% )</pre>
1135
1136 <p>to:</p>
1137
1138 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"># perf stat -d -r 5 ./getpid
1139 # output normalized for a single getpid() call
1140
1141 cycles 669.09 ( +- 11.23% )
1142 instructions 1342.04 ( +- 0.00% )
1143 IPC 2.03 ( +- 9.85% )
1144 branches 328.19 ( +- 0.00% )
1145 branch-misses 0.56 ( +- 5.35% )
1146 L1-dcache-loads 384.31 ( +- 0.00% )
1147 L1-dcache-load-misses 5.77 ( +- 84.57% )</pre>
1148
1149 <p>This compares quite well to the UEK5-baseline:</p>
1150
1151 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;"># perf stat -d -r 5 ./getpid
1152 # output normalized for a single getpid() call
1153
1154 cycles 672.90 ( +- 1.65% )
1155 instructions 1622.08 ( +- 0.00% )
1156 IPC 2.41 ( +- 1.65% )
1157 branches 321.20 ( +- 0.00% )
1158 branch-misses 0.51 ( +- 0.00% )
1159 L1-dcache-loads 401.32 ( +- 0.00% )
1160 L1-dcache-load-misses 2.28 ( +- 59.62% )</pre>
1161
1162 <p>Note for non-Skylake-X architectures: Intel Icelake and AMD Milan (the other architectures tested) cope with L1d-load-misses much better so the baseline performance is much better.</p>
1163
1164 <p>With these patches, they only show a small improvement (~10ns): Icelake has a bigger L1d-cache (48K), and a much bigger ROB. Milan also has a bigger ROB and does memory renaming and bunch of other pipeline optimizations that limit the effect of these optimizations.</p>
1165
1166 <p><strong>Endnote:</strong> what I found personally instructive was how much C really is “a portable assembler” and the significant codegen (and performance) changes that can result from minimal changes to the code.</p>
1167
1168 <h2 id="references">References</h2>
1169
1170 <ol type="1">
1171 <li>
1172 <p><code style="background:#eeeeee;border:1px solic #cccccc;">getpid()</code> has a minimal kernel execution path (only does a PID lookup), and so is generally used to measure the overhead of the syscall path.</p>
1173 </li>
1174 <li>
1175 <p>Comparing the IPC for the audit-only portion shows that a starker drop:</p>
1176
1177 <pre class="brush: bash;" style="background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;">UEK5: 1427.0 instructions # 3.41 insn per cycle
1178 UEK6: 1432.0 instructions # 2.84 insn per cycle</pre>
1179 </li>
1180 <li>
1181 <p>Alas no, alias analysis is an undecidable problem.</p>
1182 </li>
1183 <li>
1184 <p>Or for that matter, what causes the extra branch-miss.</p>
1185 </li>
1186 <li>
1187 <p>Another possibility is out-of-line code -- frequent interrupts, vmexits etc -- trashing the cache but from profiling these were a non-issue.</p>
1188 </li>
1189 <li>
1190 <p>Measured using the pearson-quotient(x, y): correlation coefficient between quantities x and y.</p>
1191 </li>
1192 <li>
1193 <p>You might notice that this analysis does not address the extra branch-miss. That's because I still have no clue what causes it.</p>
1194 </li>
1195 <li>
1196 <p>The correct fix would be to fix whatever ails the allocator. However, from a quick look at the changes that have gone into related code, it seems non-trivial to find a particular commit which points to the root cause of the skew (especially given that the skew is not constant, but varies from run-to-run.) Also, notably, the fixes described below also apply to UEK5, which means that even if UEK6 becomes faster, UEK5 will also improve somewhat.</p>
1197 </li>
1198 <li>
1199 <p>As mentioned in <a href="#cpu-parameters">CPU-parameters</a>, L1d-loads take 4-6 cycles on Skylake-X. We also know that in the good case (UEK5), this loop is capable of an IPC of 3.41 insn per cycle. So, hiding L1d-load latency is critical for good performance.</p>
1200 </li>
1201 <li>
1202 <p><a href="https://www.agner.org/optimize/instruction_tables.pdf%3E">https://www.agner.org/optimize/instruction_tables.pdf</a>, pg 298 (Skylake-X)</p>
1203 </li>
1204 <li>
1205 <p>The first form fused, needs three inputs: <code style="background:#eeeeee;border:1px solic #cccccc;">%rbx</code>, an <code style="background:#eeeeee;border:1px solic #cccccc;">imm32</code> encoding the distance to the address being compared, and an <code style="background:#eeeeee;border:1px solic #cccccc;">imm8</code> encoding the distance to the branch-dest; the second needs two registers: <code style="background:#eeeeee;border:1px solic #cccccc;">%rbx</code>, <code style="background:#eeeeee;border:1px solic #cccccc;">%r12</code> and only the <code style="background:#eeeeee;border:1px solic #cccccc;">imm8</code>.</p>
1206 </li>
1207 <li>
1208 <p>Just for context, a kernel build (x86-defconfig) makes an aggregate of 27M syscalls, with a syscall every 44us.</p>
1209 </li>
1210 </ol>
1211
1212
1213 </section>
1214 <!-- /RC84v1 -->
1215
1216 <!-- RC84v2 -->
1217 <section class="rc84v2 cpad">
1218 <div class="rc84w1 cwidth">
1219
1220 <div class="rc84bio">
1221 <div class="rc84img">
1222 <img src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/img/ui_defaultuserimage.jpg" alt="">
1223 </div>
1224 <div class="rc84blurb">
1225 <div class="blogtile-w2-inner text-wrap">
1226 <h4>Ankur Arora</h4>
1227
1228 <p></p>
1229 </div>
1230 </div>
1231 </div>
1232
1233 </div>
1234 </section>
1235 <!-- /RC84v2 -->
1236
1237
1238 </div>
1239
1240 </div>
1241 </section>
1242 <!-- /RC84v0 -->
1243
1244 <!-- /RC83v0 -->
1245 <input type="hidden" name="hiddenField" value="September 12, 2023" id="pubdate">
1246 <input type="hidden" name="hiddenField" value="linux" id="primarychannel">
1247 <div class="hydrate-container" data-hydrate="{"metaItems":[{"translatable":true,"createdDate":{"value":"2023-09-12T15:00:01.308Z","timezone":"UTC"},"fileExtension":"contentItem","name":"Ankur","description":"","language":"en-US","links":[{"href":"https://orasites-prodapp.cec.ocp.oraclecloud.com/content/published/api/v1.1/items/COREF415334566DE45208D79D6CD6FA88629?channelToken=3189ef66cf584820b5b19e6b10792d6f","rel":"self","method":"GET","mediaType":"application/json"}],"id":"COREF415334566DE45208D79D6CD6FA88629","updatedDate":{"value":"2023-09-12T15:00:01.308Z","timezone":"UTC"},"type":"Blog-Author","fields":{"twitter_handle":null,"facebook_url":null,"profile_image":null,"timezone":"EST","last_name":"Arora","bio":null,"linkedin_url":null,"middle_name":null,"first_name":"Ankur","job_title":null,"email":"ankur.a.arora"},"slug":"ankur-arora"}],"contentData":{"featured_image_display_option":null,"featured_image_alt_text":null,"attachments":null,"og_title":"Syscall latency... and some uses of speculative execution","featured_image_alternate_text":"","industry":null,"title":"Syscall latency... and some uses of speculative execution","body":"<!DOCTYPE html> <h2 id=\"introduction\">Introduction</h2>\n\n<p>Moving from UEK5 to UEK6 brought about an unwelcome surprise: an increase in syscall latency on some x86 systems. The root cause, as we will see, was slightly slower evaluation of audit rules, which, given that they are evaluated for every syscall, is not great.</p>\n\n<p>In this post we start off by exploring the root cause which turns out to not be UEK specific, it also impacts upstream kernels as well. Then we detail the fixes and how they take advantage of the speculative out-of-order nature of the CPU pipeline.</p>\n\n<p>The changes, even though they target low-level optimizations, are quite straight-forward, almost trivial.</p>\n\n<h3 id=\"background\">Background</h3>\n\n<p>Execution latency of the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">getpid()</code>[1] increased by about 15% (measured on an Intel Skylake-X system), from 191ns on UEK5, to 217ns on UEK6.</p>\n\n<p>This was measured in the usual way:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\nclock_gettime(CLOCK_MONOTONIC, &amp;start);\nfor (i = 0; i &lt; large_number; i++)\n syscall(SYS_getpid);\nclock_gettime(CLOCK_MONOTONIC, &amp;stop);</pre>\n\n<p>A quick <code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf record</code>, showed that almost all of the increased latency was in <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code> which was more expensive in UEK6.</p>\n\n<p>Oracle Exadata, where this problem was seen has 37 audit rules that are evaluated in the syscall path. Since audit only wants to log unusual or exceptional events, the benchmark would evaluate these rules in every iteration, but never generate any output. Essentially, purely local computation that became slower without there having been any material changes to the audit code or in the audit rules.</p>\n\n<h3 id=\"cpu-parameters\">CPU-parameters</h3>\n\n<p>Some Intel Skylake-X parameters that we&#39;ll make use of later:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\nL1-load-latency: 4-6 cycles\nL2-load-latency: 14 cycles \nL1-cache-size: 32K (512 cachelines: 64 sets, 8 ways each)\n\nROB size: 224 micro-ops</pre>\n\n<p>The parameters are taken from the <a href=\"https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html\">Intel SDM</a>.</p>\n\n<p><strong>Note:</strong> L1/L2 being the respective data-cache level and ROB, being the Reorder Buffer, where instructions are staged for in-order retirement.</p>\n\n<h2 id=\"root-cause-analysis\">Root cause analysis</h2>\n\n<p>Drilling down with <code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf stat -d</code>:</p>\n\n<p>UEK5 (191 ns):</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n# perf stat -d -r 5 ./getpid\n# output normalized for a single getpid() call\n\n 677.9 cycles # 3.542 GHz\n1635.0 instructions # 2.40 insn per cycle\n 325.0 branches\n 0.5 branch-misses # 0.16% of all branches\n 404.0 L1-dcache-loads\n 0.4 L1-dcache-load-misses # 0.10% of all L1-dcache accesses</pre>\n\n<p>UEK6 (217ns):</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n# perf stat -d -r 5 ./getpid\n# output normalized for a single getpid() call\n\n 770.4 cycles # 3.545 GHz\n1652.0 instructions # 2.14 insn per cycle\n 332.2 branches\n 1.5 branch-misses # 0.45% of all branches\n 407.3 L1-dcache-loads\n 8.6 L1-dcache-load-misses # 2.13% of all L1-dcache accesses</pre>\n\n<p>Comparing, this is an increase of ~100 cycles with the L1d-loads and instruction counts being almost identical across UEK5 and UEK6. This underscores the fact that audit code which forms the bulk of instructions executed hasn&rsquo;t changed all that much.</p>\n\n<p>The IPC is commensurately lower[2]. The proximal cause seems to be the increased L1d-load-misses and the one extra branch-miss.</p>\n\n<p>These observations were confirmed via enough non-correlated runs (with intervening reboot for each) and so are statistically significant. The L1d-load-miss numbers are somewhat variable across boot cycles, but the trend is close to what we see above.</p>\n\n<h3 id=\"audit_filter_syscall\"><code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code></h3>\n\n<p>From <code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf record</code> we know that the bulk of the increased runtime went to <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code>. The procedure itself is primarily a loop that walks the list of rules, calling <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code> for each rule to check if it needs to be evaluated for the current syscall. For <code style=\"background:#eeeeee;border:1px solic #cccccc;\">getpid()</code> the answer will be <code style=\"background:#eeeeee;border:1px solic #cccccc;\">false</code> most of the time (32 of 37 times.)</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\naudit_filter_syscall(...) {\n struct audit_entry *e; \n struct audit_entry *ctx;\n\n list = audit_filter_list[AUDIT_FILTER_EXIT]; \n\n list_for_each_entry_rcu(e, list, list) {\n\n if (audit_in_mask(&amp;e-&gt;rule, ctx-&gt;major) &amp;&amp; \n audit_filter_rules(tsk, &amp;e-&gt;rule, ctx, NULL,\n &amp;state, false, x)) { \n rcu_read_unlock(); \n ctx-&gt;current_state = state;\n return state;\n }\n }\n\n\n}\n \naudit_in_mask(const struct audit_krule *rule, unsigned long val) {\n if (val &gt; 0xffffffff)\n return false; \n\n /*\n * val contains the current syscall number. AUDIT_WORD does\n * some bit shifting on it.\n */\n word = AUDIT_WORD(val);\n if (word &gt;= AUDIT_BITMASK_SIZE)\n return false;\n\n bit = AUDIT_BIT(val);\n\n /*\n * The load in rule-&gt;mask[word] depends on the audit_krule (which\n * hangs off the current rule entry) and the syscall number.\n */\n return rule-&gt;mask[word] &amp; bit;\n}\naudit_filter_rules(...) {\n /*\n * Large switch statement which we ignore for the rest of this\n * analysis because, as we will see later, loads executed in it don&#39;t\n * have an &quot;interesting&quot; alignment and so their latency should be easy\n * enough to hide.\n */\n}</pre>\n\n<h3 id=\"memory-accesses\">Memory accesses</h3>\n\n<p>Next let&rsquo;s look at the data structures accessed in the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code> loop and where the L1d-load-misses might be coming from.</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n/* Data structure layout annotated with size and cacheline occupancy\n * information using pahole. */\n\nstruct audit_entry { /* via audit_filter_list[AUDIT_FILTER_EXIT] */\n\n struct list_head list; /* 0 16 */\n struct callback_head rcu; /* 16 16 */\n struct audit_krule rule; /* 32 376 */\n ...\n /* size: 408, cachelines: 7, members: 3 */\n /* last cacheline: 24 bytes */\n};\n\nstruct audit_krule { /* inlined in struct audit_entry */\n ...\n u32 mask[64]; /* 16 256 */\n ...\n /* size: 376, cachelines: 6, members: 17 */\n /* last cacheline: 56 bytes */\n};\n\nstruct audit_context {\n ...\n int major; /* 20 4 */\n ...\n /* size: 920, cachelines: 15, members: 46 (slightly larger on UEK6) */\n /* sum members: 912, holes: 2, sum holes: 8 */\n /* last cacheline: 24 bytes */\n};</pre>\n\n<p>The effective execution loop in <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code> (with cacheline access annotations):</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\nstruct audit_entry *e = &amp;audit_filter_list[AUDIT_FILTER_EXIT];\n\nfor_each_iteration {\n e = e-&gt;next; /* cacheline-0 of audit_entry */\n if (e == list)\n jmp out;\n if (audit_in_mask(e-&gt;rule.mask, /* cacheline-0 of audit_entry */\n ctx-&gt;major)) /* cacheline-0 of audit_context */\n audit_filter_rules(e-&gt;rule);\n}\nout:</pre>\n\n<p>As the annotations above mention, there are a total of three loads:</p>\n\n<ol type=\"1\">\n\t<li>Pointer chasing in <code style=\"background:#eeeeee;border:1px solic #cccccc;\">e-&gt;next</code>: the first cacheline of <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_entry</code>.</li>\n\t<li><code style=\"background:#eeeeee;border:1px solic #cccccc;\">e-&gt;rule.mask[]</code>: accesses the same cacheline as load (1) above.</li>\n\t<li><code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code>: accesses the first cacheline of <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_context</code>.</li>\n</ol>\n\n<p>Loads (1) and (2) will access a total of 37 cachelines, corresponding to a rule per iteration. Also notice that every single basic block in the rest of the iteration (apart from some error checking in <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code>) has data dependence on the evaluation of <code style=\"background:#eeeeee;border:1px solic #cccccc;\">e=e-&gt;next</code>. Worse this is a loop carried dependency, so each iteration depends on the previous one.</p>\n\n<p>The cacheline for load (3) is accessed once every iteration. This load is unnecessary, <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> contains the syscall number, which is a constant for the duration of the syscall. However, because the compiler&rsquo;s alias analysis cannot prove that <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> is not mutilated, it does not get cached in a register. This also means that <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code> will do out-of-bound validation checks related to <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> over and over.</p>\n\n<p>Recalling the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf-stat -d</code> output above there are a total of around 400 L1d-loads for each <code style=\"background:#eeeeee;border:1px solic #cccccc;\">getpid()</code> call. Of those, the loop does a total of 37*3 loads which map to a total of 38 unique cachelines.</p>\n\n<p>Alright, I hear you think: granted, walking linked-lists is difficult, there are a lot of cachelines in a lot of iterations or whatever, life is hard and the compiler doesn&rsquo;t know what it is doing[3]. Even given all of that, nothing here has changed from UEK5 to UEK6, so none of this explains why UEK6 would incur more L1d-load-misses[4].</p>\n\n<p>Which is true, so that&rsquo;s next.</p>\n\n<h3 id=\"theory-of-the-case\">Theory of the case</h3>\n\n<p>From the background above, we know that the loop is pure computation, and purely local computation at that, so code changes elsewhere should have no effect. And there were no significant code changes from UEK5 to UEK6, so the loop is unchanged (which also applies to the generated assembly.)</p>\n\n<p>Now insofar as L1d-load-misses are concerned: the number of cachelines accessed (from about 400 L1d-loads per <code style=\"background:#eeeeee;border:1px solic #cccccc;\">getpid()</code> call, not all of which are to unique cachelines) amount to a number comfortably below the Skylake-X L1d-cache capacity of 512 cachelines. So this loop should not incur any capacity misses.</p>\n\n<p>Which leaves conflict misses as the probable cause[5]. Skylake-X has an 8-way associative L1: if more than 8 loads in the loop map to the same cache-set some accesses would incur conflict misses.</p>\n\n<p>Accesses in the loop and how they map to cache-sets:</p>\n\n<ul>\n\t<li><code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_entry</code>: aligns at a 512B boundary, which limits it to cache-sets <code style=\"background:#eeeeee;border:1px solic #cccccc;\">{0, 8, 16, ... 56}</code>, for a total of 8*8 cache-slots.</li>\n\t<li><code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_context</code>: aligns at a 1024B boundary, which resolves to cache-sets <code style=\"background:#eeeeee;border:1px solic #cccccc;\">{0, 16, 32, 48}</code>, for a total of 4*8 cache-slots. As described earlier, this is a single cacheline which competes with a subset of the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_entry</code> cachelines.</li>\n</ul>\n\n<p>Even then, this is 37 cachelines slotted into 64 slots and another slotting into 32 of those 64. This should be easy enough to satisfy, assuming that the kernel allocator has a reasonably sane distribution and isn&rsquo;t skewed towards a particular set of cachelines (or is similarly skewed on both UEK5 and UEK6.)</p>\n\n<h3 id=\"allocation-skew\">Allocation skew</h3>\n\n<p>If, allocations for <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_entry</code> were distributed uniformly, they would map into cache-sets uniformly, ending with similar populations across the cache-sets. This would give a cacheline-spread metric of ~0 (obtained by calculating the standard-deviation of populations across cache-sets.)</p>\n\n<p>What we see:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\ncacheline-spread on UEK5: 1.58\ncacheline-spread on UEK6: 1.91</pre>\n\n<p>(These results are from a large number (&gt; 100) of non-correlated runs. <code style=\"background:#eeeeee;border:1px solic #cccccc;\">auditd</code> allocates at boot, so this was done by rebooting between each run.)</p>\n\n<p>From these numbers, UEK5 is far from a flat distribution, and UEK6 is somewhat worse, but not dispositively so. Additionally, a slight imbalance will not cause performance degradation: that happens only after cache conflicts kick in, which is after cache-set population crosses the associativity threshold.</p>\n\n<p>To validate this, we measure how well cycles correlate[6] with 1) with L1d-misses, and 2) cacheline-spread:</p>\n<style type=\"text/css\">.divTable {\n display: table;\n width: 80%;\n}\n.divTableRow {\n display: table-row;\n}\n.divTableHeading {\n display: table-header-group;\n background-color: #ddd;\n font-weight: bold;\n}\n.divTableCell {\n display: table-cell;\n padding: 3px 10px;\n border: 1px solid #999999;\n}\n</style>\n<p>&nbsp;</p>\n\n<div class=\"divTable\">\n<div class=\"divTableHeading\">\n<div class=\"divTableCell\">Kernel</div>\n\n<div class=\"divTableCell\">cycles:L1d-misses</div>\n\n<div class=\"divTableCell\">cycles:cacheline-spread</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">UEK5</div>\n\n<div class=\"divTableCell\">0.74</div>\n\n<div class=\"divTableCell\">0.22</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">UEK6</div>\n\n<div class=\"divTableCell\">0.74</div>\n\n<div class=\"divTableCell\">0.61</div>\n</div>\n</div>\n\n<p>&nbsp;</p>\n\n<p>For both UEK5 and UEK6, &ldquo;cycles:L1d-misses&rdquo; is tightly correlated (though the value of 0.74 for both is happenstance) which makes sense. &ldquo;cycles:cacheline-spread&rdquo;, however, is well correlated only on UEK6, not UEK5. This suggests that the UEK6 allocator skew is meaningfully worse, enough to cause lower performance.</p>\n\n<p>Alright, having beaten this dead horse enough, let&rsquo;s figure out how to fix it next[7].</p>\n\n<h2 id=\"speeding-it-up\">Speeding it up</h2>\n\n<p>To get back our lost performance, our task is simple: optimize a hot-loop[8] which is itself executed in the hot syscall path. Compounding the problem, the critical load in the loop is accessed via a linked list.</p>\n\n<p>Stated like that, it sounds pretty bad. But, as we will see the structure of the problem helps quite a bit:</p>\n\n<ol type=\"1\">\n\t<li>On a sane system, the common-case is extremely common, syscalls are frequent, and audit logging is unusual. This means that low branch mispreds are not unusual and something we might even depend on.</li>\n\t<li>We are optimizing a no-op loop: the loop walks a bunch of rules, does error checking, and decides if it needs to log. In the common-case, it will conclude that it doesn&rsquo;t. (This is really (1) restated to stress the no-op nature of the loop.)</li>\n</ol>\n\n<p>A no-op loop implies that the code does not actually care about most of the values it computes. It just inches towards a foregone conclusion.</p>\n\n<p>This it does (as all code does) by means of dependency chains that transform the input state to output. Here, most dependency chains are short and, are really <em>only used to predict the control flow</em>. The only long dependency chain, woven through all the loop iterations, is the one walking the linked-list.</p>\n\n<p>Now, critically since the branches are predicted perfectly or almost so, the control flow can run quite a bit further than any loads and dependent computation. The control flow thus essentially feeds these loads and other instructions to the ROB, where they wait until resources/dependencies become available, compute the output from their chain which, to reiterate, will only be used to predict the control flow.</p>\n\n<p>Given that the control flow is already feeding instructions from the correct direction, these are in effect orphan chains that eventually retire without anyone having cared for the output they compute or how long that took.</p>\n\n<p>Except: this happy state continues only until we run into a resource constraint. For instance, the size of the ROB on Skylake-X is 224 entries and each loop iteration is ~20 instructions. This means instructions worth around 10 loop iterations can be present in the ROB. Now, given that instructions retire on x86 in-order, long running instructions (L1d-load-misses of course, but also L1d-load hits[9]) with long dependence chains would slow retirement down, even were control-flow to be predicted perfectly.</p>\n\n<p>Bearing these observations in mind, our fixes will try to reduce the amount and cost of work per loop iteration. This allows the loop to retire as close to the gating latency of any long running instructions in the loop.</p>\n\n<h3 id=\"cache-ctx-major-in-audit_filter_syscall\">Cache <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> in <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code></h3>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n@@ -785,13 +785,14 @@ static enum audit_state audit_filter_syscall(struct task_struct *tsk,\n {\n struct audit_entry *e;\n enum audit_state state;\n+ unsigned long major = ctx-&gt;major;\n\n if (auditd_test_task(tsk))\n return AUDIT_DISABLED;\n\n rcu_read_lock();\n list_for_each_entry_rcu(e, list, list) {\n- if (audit_in_mask(&amp;e-&gt;rule, ctx-&gt;major) &amp;&amp;\n+ if (audit_in_mask(&amp;e-&gt;rule, major) &amp;&amp;\n audit_filter_rules(tsk, &amp;e-&gt;rule, ctx, NULL,\n &amp;state, false)) {\n rcu_read_unlock();</pre>\n\n<p>Caching <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> in a local variable helps in two ways:</p>\n\n<ul>\n\t<li>Explicitly indicates to the compiler that there are no stores to the cached value. <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code> operates on <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> doing some bit-shifting and error checking. Now that the compiler knows that <code style=\"background:#eeeeee;border:1px solic #cccccc;\">major</code> is not modified, it can hoist most of that logic out of the loop so it is not reevaluated over-and-over in every loop iteration.</li>\n\t<li>As described earlier, <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_context</code> has similar natural alignment concerns as <code style=\"background:#eeeeee;border:1px solic #cccccc;\">struct audit_entry</code>. Allowing the compiler to cache <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code> in a register (or on the stack) reduces one potential source of contention.</li>\n</ul>\n\n<p>With this change the number of instructions executed/loop-iteration reduce by 8 (of 20.) Note that most of those were almost free ALU instructions.</p>\n\n<p>L1d-loads: we removed one L1d-load but added two (due to the compiler now spilling and reloading some state to/from the stack.) However, given that stack accesses are much less likely to have conflicting alignment constraints, the increased loads are less of a concern than the one we got rid of.</p>\n\n<p>cycles: improve by about 40 cycles. This is because the greater room in the ROB allows our almost perfect branch prediction to speculatively run even further ahead of other instructions.</p>\n\n<p>Change in latency for UEK6:</p>\n\n<div class=\"divTable\">\n<div class=\"divTableHeading\">\n<div class=\"divTableCell\">Version</div>\n\n<div class=\"divTableCell\">Min<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Mean<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Median<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Max<br />\n(ns)</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">baseline</div>\n\n<div class=\"divTableCell\">196.26</div>\n\n<div class=\"divTableCell\">212.00</div>\n\n<div class=\"divTableCell\">207.80</div>\n\n<div class=\"divTableCell\">240.52</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">ctx-&gt;major</div>\n\n<div class=\"divTableCell\">183.50</div>\n\n<div class=\"divTableCell\">201.41</div>\n\n<div class=\"divTableCell\">198.80</div>\n\n<div class=\"divTableCell\">226.93</div>\n</div>\n</div>\n\n<p>&nbsp;</p>\n\n<p>From the min-max range, there is a rather large variation in latency that&rsquo;s caused by variations in allocation resulting in high or low cacheline-spread. In almost all cases though, the latency improves by ~10ns or thereabouts.</p>\n\n<p>That said, after removing 8 instructions and one load (and adding two less consequential loads), the performance gain is rather miniscule: ~1 cycle/iteration. Just that the loop executes 37 times, so we make it up in volume.</p>\n\n<p>More details (<code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf-stat</code> and the before/after versions of the generated code) in <a href=\"https://github.com/oracle/linux-uek/commit/87a39a3d2ca9a5c7e4d35e4cf4b839c53cc0678d\">UEK6 commit-1</a> and in <a href=\"https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/auditsc.c?id=069545997510833281f45f83e097017b9fef19b7\">Upstream commit-1</a>.</p>\n\n<h3 id=\"annotate-branch-direction-for-audit_in_mask\">Annotate branch direction for <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code></h3>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n@@ -790,12 +790,13 @@ static enum audit_state audit_filter_syscall(struct task_struct *tsk,\n rcu_read_lock();\n list_for_each_entry_rcu(e, list, list) {\n - if (audit_in_mask(&amp;e-&gt;rule, major) &amp;&amp;\n - audit_filter_rules(tsk, &amp;e-&gt;rule, ctx, NULL,\n - &amp;state, false)) {\n ...\n + if (unlikely(audit_in_mask(&amp;e-&gt;rule, major))) {\n + if (audit_filter_rules(tsk, &amp;e-&gt;rule, ctx, NULL,\n + &amp;state, false)) {</pre>\n\n<p>Annotate <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_in_mask()</code> as <code style=\"background:#eeeeee;border:1px solic #cccccc;\">unlikely()</code> to allow the compiler to pessimize the call to <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_rules()</code>. Two reasons for this change:</p>\n\n<ul>\n\t<li>The primary motivation was to get rid of the extra branch mispred. This change succeeds in that task but it is unclear why: there&rsquo;s no significant change in the basic-block structure. The only change is from a branch inversion due to the unlikely clause.</li>\n\t<li>The branch inversion means that the not-taken direction is chosen more often: 32/37 times (changing from 5/37 earlier.) The issue-latency for not-taken branches is 0.5-1 cycles, for taken branches 1-2 cycles[10] is slightly cheaper.</li>\n</ul>\n\n<p>L1d-loads: reduce by 2 for each loop iteration. This is because the spills and reloads introduced in the &ldquo;Cache <code style=\"background:#eeeeee;border:1px solic #cccccc;\">ctx-&gt;major</code>&hellip;&rdquo; patch have now been shifted to the unlikely path (the prologue and epilogue of the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_rules()</code> call.)</p>\n\n<p>cycles: performance improves on average by ~30 cycles/call.</p>\n\n<p>Change in latency for UEK6:</p>\n\n<div class=\"divTable\">\n<div class=\"divTableHeading\">\n<div class=\"divTableCell\">Version</div>\n\n<div class=\"divTableCell\">Min<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Mean<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Median<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Max<br />\n(ns)</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">ctx-&gt;major</div>\n\n<div class=\"divTableCell\">183.50</div>\n\n<div class=\"divTableCell\">201.41</div>\n\n<div class=\"divTableCell\">198.80</div>\n\n<div class=\"divTableCell\">226.93</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">ctx-&gt;major+annot</div>\n\n<div class=\"divTableCell\">165.26</div>\n\n<div class=\"divTableCell\">188.72</div>\n\n<div class=\"divTableCell\">184.25</div>\n\n<div class=\"divTableCell\">230.34</div>\n</div>\n</div>\n\n<p>&nbsp;</p>\n\n<p>More details (<code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf-stat</code> and the before/after versions of the generated code) in <a href=\"https://github.com/oracle/linux-uek/commit/0288dbdbfb5768ad8ae8a445c72f523bcb99eca0\">UEK6 commit-2</a>.</p>\n\n<h3 id=\"remove-static-linkage-from-audit_filter_syscall\">Remove static linkage from <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code></h3>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n@@ -777,7 +777,7 @@ static bool audit_in_mask(const struct audit_krule *rule, unsigned long\n * also not high enough that we already know we have to write an audit\n * record (i.e., the state is AUDIT_SETUP_CONTEXT or AUDIT_BUILD_CONTEXT).\n */\n -static enum audit_state audit_filter_syscall(struct task_struct *tsk,\n +enum audit_state audit_filter_syscall(struct task_struct *tsk,\n struct audit_context *ctx,\n struct list_head *list)</pre>\n\n<p><code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code> is only used locally in the file and so is marked <code style=\"background:#eeeeee;border:1px solic #cccccc;\">static</code>. Additionally, it&rsquo;s only ever called with a fixed <code style=\"background:#eeeeee;border:1px solic #cccccc;\">list</code> value of <code style=\"background:#eeeeee;border:1px solic #cccccc;\">&amp;audit_filter_list[AUDIT_FILTER_EXIT])</code>.</p>\n\n<p>GCC&rsquo;s constant propagation pass makes use of these two things to, quite reasonably, const-propagate the third argument to the point of use.</p>\n\n<p>This causes the exit check in the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">list_for_each</code> loop to look like this:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\naudit_filter_syscall.constprop.18(task, ctx):\n 0: 48 8b 1b mov (%rbx),%rbx\n 3: 48 81 fb e0 67 ac 82 cmp $0xffffffff82ac67e0,%rbx\n ffffffff8118b5ed: R_X86_64_32S audit_filter_list+0x40\n 10: 75 e2 jne start_iter</pre>\n\n<p>while, without const-propagation it would have looked like this:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\naudit_filter_syscall(task, ctx, list):\n 0: 48 8b 1b mov (%rbx),%rbx\n 3: 4c 39 e3 cmp %r12,%rbx\n 6: 75 e6 jne start_iter</pre>\n\n<p>Now either one ought to be alright, both <code style=\"background:#eeeeee;border:1px solic #cccccc;\">cmp imm32,r</code> and <code style=\"background:#eeeeee;border:1px solic #cccccc;\">cmp r,r</code> forms are equivalent with a latency of 1 cycle, and both are a single micro-op each.</p>\n\n<p>The second form of the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">cmp</code>, however, can be macro-op fused with the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">jne</code>; not entirely sure if the first form can be[11]. The second form is also denser, though that&rsquo;s not a concern here.</p>\n\n<p>Disallowing GCC from making assumptions about calling contexts by removing the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">static</code> linkage from <code style=\"background:#eeeeee;border:1px solic #cccccc;\">audit_filter_syscall()</code> forces it to pass the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">list</code> parameter in a register which results in a small performance improvement: ~20 cycles (about 0.5 cycles/loop iteration.)</p>\n\n<p>Change in latency for UEK6:</p>\n\n<div class=\"divTable\">\n<div class=\"divTableHeading\">\n<div class=\"divTableCell\">Version</div>\n\n<div class=\"divTableCell\">Min<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Mean<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Median<br />\n(ns)</div>\n\n<div class=\"divTableCell\">Max<br />\n(ns)</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">ctx-&gt;major+annot</div>\n\n<div class=\"divTableCell\">165.26</div>\n\n<div class=\"divTableCell\">188.72</div>\n\n<div class=\"divTableCell\">184.25</div>\n\n<div class=\"divTableCell\">230.34</div>\n</div>\n\n<div class=\"divTableRow\">\n<div class=\"divTableCell\">ctx-&gt;major+annot+extern</div>\n\n<div class=\"divTableCell\">159.88</div>\n\n<div class=\"divTableCell\">184.35</div>\n\n<div class=\"divTableCell\">177.62</div>\n\n<div class=\"divTableCell\">250.82</div>\n</div>\n</div>\n\n<p>&nbsp;</p>\n\n<p>More details (<code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf-stat</code> and the before/after versions of the generated code) in <a href=\"https://github.com/oracle/linux-uek/commit/5a74015e20bff63d1052359fbc2c3418e0f6bc4e\">UEK6 commit-3</a> and, <a href=\"https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/auditsc.c?id=50979953c0c41e929e5f955800da68e1bb24c7ab\">Upstream commit-3</a>.</p>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>The audit subystem is fairly stable in the Linux kernel, not given to frequent changes. So it was puzzling when it became slower in recent kernels, and because a primary user is the syscall path, concerning[12].</p>\n\n<p>The cause turned out to be higher skew in allocated buffers which results in more lopsided cache-set distribution.</p>\n\n<p>The fixes compensate for the higher costs in the loop by taking advantage of the peculiarities of the execution path and optimizing for the speculative nature of the CPU pipeline.</p>\n\n<p>The three patches, in sum reduce the overhead by about 30ns (~100 cycles).</p>\n\n<p>Final <code style=\"background:#eeeeee;border:1px solic #cccccc;\">perf stat -d -r 5</code> go from:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n# perf stat -d -r 5 ./getpid\n# output normalized for a single getpid() call\n\ncycles 761.65 ( +- 5.22% )\ninstructions 1639.17 ( +- 0.00% )\nIPC 2.18 ( +- 5.50% )\nbranches 328.21 ( +- 0.00% )\nbranch-misses 1.37 ( +- 6.56% )\nL1-dcache-loads 404.35 ( +- 0.00% )\nL1-dcache-load-misses 7.99 ( +- 70.71% )</pre>\n\n<p>to:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n# perf stat -d -r 5 ./getpid\n# output normalized for a single getpid() call\n\ncycles 669.09 ( +- 11.23% )\ninstructions 1342.04 ( +- 0.00% )\nIPC 2.03 ( +- 9.85% )\nbranches 328.19 ( +- 0.00% )\nbranch-misses 0.56 ( +- 5.35% )\nL1-dcache-loads 384.31 ( +- 0.00% )\nL1-dcache-load-misses 5.77 ( +- 84.57% )</pre>\n\n<p>This compares quite well to the UEK5-baseline:</p>\n\n<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\n# perf stat -d -r 5 ./getpid\n# output normalized for a single getpid() call\n\ncycles 672.90 ( +- 1.65% )\ninstructions 1622.08 ( +- 0.00% )\nIPC 2.41 ( +- 1.65% )\nbranches 321.20 ( +- 0.00% )\nbranch-misses 0.51 ( +- 0.00% )\nL1-dcache-loads 401.32 ( +- 0.00% )\nL1-dcache-load-misses 2.28 ( +- 59.62% )</pre>\n\n<p>Note for non-Skylake-X architectures: Intel Icelake and AMD Milan (the other architectures tested) cope with L1d-load-misses much better so the baseline performance is much better.</p>\n\n<p>With these patches, they only show a small improvement (~10ns): Icelake has a bigger L1d-cache (48K), and a much bigger ROB. Milan also has a bigger ROB and does memory renaming and bunch of other pipeline optimizations that limit the effect of these optimizations.</p>\n\n<p><strong>Endnote:</strong> what I found personally instructive was how much C really is &ldquo;a portable assembler&rdquo; and the significant codegen (and performance) changes that can result from minimal changes to the code.</p>\n\n<h2 id=\"references\">References</h2>\n\n<ol type=\"1\">\n\t<li>\n\t<p><code style=\"background:#eeeeee;border:1px solic #cccccc;\">getpid()</code> has a minimal kernel execution path (only does a PID lookup), and so is generally used to measure the overhead of the syscall path.</p>\n\t</li>\n\t<li>\n\t<p>Comparing the IPC for the audit-only portion shows that a starker drop:</p>\n\n\t<pre class=\"brush: bash;\" style=\"background:#eeeeee;border:1px solid #cccccc;padding:5px 10px;\">\nUEK5: 1427.0 instructions # 3.41 insn per cycle\nUEK6: 1432.0 instructions # 2.84 insn per cycle</pre>\n\t</li>\n\t<li>\n\t<p>Alas no, alias analysis is an undecidable problem.</p>\n\t</li>\n\t<li>\n\t<p>Or for that matter, what causes the extra branch-miss.</p>\n\t</li>\n\t<li>\n\t<p>Another possibility is out-of-line code -- frequent interrupts, vmexits etc -- trashing the cache but from profiling these were a non-issue.</p>\n\t</li>\n\t<li>\n\t<p>Measured using the pearson-quotient(x, y): correlation coefficient between quantities x and y.</p>\n\t</li>\n\t<li>\n\t<p>You might notice that this analysis does not address the extra branch-miss. That&#39;s because I still have no clue what causes it.</p>\n\t</li>\n\t<li>\n\t<p>The correct fix would be to fix whatever ails the allocator. However, from a quick look at the changes that have gone into related code, it seems non-trivial to find a particular commit which points to the root cause of the skew (especially given that the skew is not constant, but varies from run-to-run.) Also, notably, the fixes described below also apply to UEK5, which means that even if UEK6 becomes faster, UEK5 will also improve somewhat.</p>\n\t</li>\n\t<li>\n\t<p>As mentioned in <a href=\"#cpu-parameters\">CPU-parameters</a>, L1d-loads take 4-6 cycles on Skylake-X. We also know that in the good case (UEK5), this loop is capable of an IPC of 3.41 insn per cycle. So, hiding L1d-load latency is critical for good performance.</p>\n\t</li>\n\t<li>\n\t<p><a href=\"https://www.agner.org/optimize/instruction_tables.pdf%3E\">https://www.agner.org/optimize/instruction_tables.pdf</a>, pg 298 (Skylake-X)</p>\n\t</li>\n\t<li>\n\t<p>The first form fused, needs three inputs: <code style=\"background:#eeeeee;border:1px solic #cccccc;\">%rbx</code>, an <code style=\"background:#eeeeee;border:1px solic #cccccc;\">imm32</code> encoding the distance to the address being compared, and an <code style=\"background:#eeeeee;border:1px solic #cccccc;\">imm8</code> encoding the distance to the branch-dest; the second needs two registers: <code style=\"background:#eeeeee;border:1px solic #cccccc;\">%rbx</code>, <code style=\"background:#eeeeee;border:1px solic #cccccc;\">%r12</code> and only the <code style=\"background:#eeeeee;border:1px solic #cccccc;\">imm8</code>.</p>\n\t</li>\n\t<li>\n\t<p>Just for context, a kernel build (x86-defconfig) makes an aggregate of 27M syscalls, with a syscall every 44us.</p>\n\t</li>\n</ol>\n","translate":false,"og_description":"An in-depth exploration into why syscall latency increased on some x86 kernels in recent kernels. ","featuredpost":false,"audience":null,"product":null,"comments":true,"meta_title":"Syscall latency... and some uses of speculative execution","time_to_read":23,"author":[{"id":"COREF415334566DE45208D79D6CD6FA88629","type":"Blog-Author","typeCategory":"ContentType","links":[]}],"translated-pages":null,"canonical_url":null,"featured_image":{"id":"CONTCF8836A82B014903A5283C76DE901346","type":"DigitalAsset","typeCategory":"DigitalAssetType","links":[]},"og_image":{"id":"CONTCF8836A82B014903A5283C76DE901346","type":"DigitalAsset","typeCategory":"DigitalAssetType","links":[]},"meta_description":"An in-depth exploration into why syscall latency increased on some x86 kernels in recent kernels. ","meta_robots":"index, follow","primary_channel":"linux","globalhomepagefeaturedpost":false,"publish_date":{"value":"2023-09-12T15:00:00.000Z","timezone":"UTC","formated":"September 12, 2023"},"desc":"An in-depth exploration into why syscall latency increased on some x86 kernels in recent kernels. ","author_id":"CORE8B88E20204C04A0DADCEBC0499683C49","categories":[{"category":"Technologies","pageUrl":"../category/lnx-technologies"},{"category":"Linux Kernel Development","pageUrl":"../category/lnx-linux-kernel-development"}]}}"></div>
1248 <!-- -->
1249 <script>
1250 window.SCSMacros = window.SCSMacros || {};
1251 var pubdate = document.getElementById("pubdate").value;
1252 window.SCSMacros.getCreationdateMacro = pubdate;
1253
1254
1255 </script>
1256 <script>
1257 if (SCS && SCS['siteId'] === "Blogs-Home") {
1258 var Primarychannel = document.getElementById("primarychannel").value;
1259 if(Primarychannel != 'undefined' && Primarychannel != 'Blogs-Home'){
1260 var slug = window.location.pathname.split('/')[2];
1261 var domain = window.location.origin;
1262 if(domain === "https://blogs.oracle.com"){
1263 window.location.replace("https://blogs.oracle.com/"+Primarychannel+"/post/"+slug);
1264 }else{
1265 window.location.replace("https://blogs-stage.oracle.com/"+Primarychannel+"/post/"+slug);
1266 }
1267 }
1268 }
1269 </script>
1270
1271 <script type="text/javascript">
1272 /*! ORACLE - TRACKING URL */
1273 $(document).ready(function() {
1274 const oracleLinks = document.querySelectorAll('a[href*="go.oracle.com"][data-trackas]');
1275
1276 oracleLinks.forEach(link => {
1277 const url = new URL(link.href);
1278
1279 if (!url.searchParams.has('source') && !url.searchParams.has('src1')) {
1280 const currentUrlParams = new URLSearchParams(window.location.search);
1281 const existingUrlParams = new URLSearchParams(url.search);
1282
1283 if (currentUrlParams.has('source')) {
1284 currentUrlParams.set('src1', currentUrlParams.get('source'));
1285 currentUrlParams.delete('source');
1286 }
1287
1288 let mergedParams = existingUrlParams.toString();
1289 if (mergedParams) {
1290 mergedParams += '&';
1291 } else {
1292 mergedParams += '?';
1293 }
1294 mergedParams += currentUrlParams.toString();
1295
1296 url.search = mergedParams;
1297
1298 link.href = decodeURIComponent(url.toString());
1299
1300 }
1301 });
1302 });
1303 </script>
1304
1305 </div>
1306 </div>
1307 </div>
1308 </div>
1309 </div>
1310 </div></div></div></div></div>
1311 <!-- <div class="scs-slot" id="category-id"></div> -->
1312 <!-- RH03v5 -->
1313 <div id="Next-Previous-Posts" class="scs-slot"><div class="scs-row"><div class="scs-col" style="width: 100%;"><div id="a057a3dc-2397-4b35-88dc-e9904a3f1789"><div class="scs-component-bounding-box"><!-- -->
1314 <div>
1315 <div class="scs-custom-component scs-component scs-component-default-style" style="margin-top:5px;margin-right:5px;margin-bottom:5px;margin-left:5px;">
1316 <div class="scs-component-content" style="width:100%;">
1317 <div style="" class="scs-custom-component-wrapper">
1318 <div id="a057a3dc-2397-4b35-88dc-e9904a3f1789customComponentDiv" data-scs-hydrate="true" data-scs-contenttype="Blog-Post" data-asset-operation="view:CORE8B88E20204C04A0DADCEBC0499683C49">
1319 <section class="rc83 rc83v0 rw-neutral-00bg cpad xwidth">
1320 <div class="rc83w1 cwidth">
1321 <div class="rc83pagenav">
1322 <div class="rc83nav-lt">
1323 <a href="oracle-linux-automation-manager-21" class="rc83arrow-lt">
1324 <div class="icn-img icn-chevron-left"><br></div>
1325 <p id="PreviousPostText">Previous Post</p>
1326 </a>
1327 <h4>Discover the Latest Advancements in Automation with Oracle Linux Automation Manager 2.1</h4>
1328 <div class="rc83sub">
1329 <span><a href="/authors/monica-s">Monica S</a> | </span><span>3</span><span> min read</span>
1330 </div>
1331 </div>
1332 <div class="rc83nav-rt">
1333 <a href="get-inspired-at-oracle-cloudworld-2023hear-from-customers-technical-industry-experts-and-executives-and-get-your-questions-answered" class="rc83arrow-rt">
1334 <p id="NextPostText">Next Post</p>
1335 <div class="icn-img icn-chevron-right"><br></div>
1336 </a>
1337 <h4>Get inspired at Oracle CloudWorld 2023—hear from customers, technical industry experts, and executives and get your questions answered</h4>
1338 <div class="rc83sub">
1339 <span><a href="/authors/michele-resta">Michele Resta</a> | </span><span>3</span><span> min read</span>
1340 </div>
1341 </div>
1342 </div>
1343 </div>
1344 </section>
1345
1346 </div>
1347 </div>
1348 </div>
1349 </div>
1350 </div>
1351 </div></div></div></div></div>
1352 <!-- <div class="scs-slot" id="recent-posts"></div> -->
1353 <!-- U10v6 -->
1354 <div class="u10 u10v6" data-trackas="ffooter" data-ocomid="redwood">
1355
1356 <div class="u10w1">
1357
1358 <div class="u10w2">
1359 <div class="u10w3">
1360 <h5>Resources for</h5>
1361 <ul>
1362 <li><a href="https://www.oracle.com/corporate/">About</a></li>
1363 <li><a href="https://www.oracle.com/corporate/careers/"
1364 data-lbl="about-oracle:careers">Careers</a></li>
1365 <li><a href="https://developer.oracle.com">Developers</a></li>
1366 <li><a href="https://investor.oracle.com/home/default.aspx">Investors</a></li>
1367 <li><a href="https://www.oracle.com/partner/">Partners</a></li>
1368 <li><a href="https://www.oracle.com/startup/">Startups</a></li>
1369 </ul>
1370 </div>
1371 </div>
1372 <div class="u10w2">
1373 <div class="u10w3">
1374 <h5>Why Oracle</h5>
1375 <ul>
1376 <li><a href="https://www.oracle.com/corporate/analyst-reports.html">Analyst Reports</a></li>
1377 <li><a href="https://www.oracle.com/cx/what-is-crm/ ">Best CRM</a></li>
1378 <li><a href="https://www.oracle.com/cloud/economics/">Cloud Economics</a></li>
1379 <li><a href="https://www.oracle.com/corporate/citizenship/">Corporate Responsibility</a>
1380 </li>
1381 <li><a href="https://www.oracle.com/corporate/careers/diversity-inclusion/">Diversity and
1382 Inclusion</a></li>
1383 <li><a href="https://www.oracle.com/corporate/security-practices/">Security Practices</a>
1384 </li>
1385 </ul>
1386 </div>
1387 </div>
1388 <div class="u10w2">
1389 <div class="u10w3">
1390 <h5>Learn</h5>
1391 <ul>
1392 <li><a href="https://www.oracle.com/cx/service/what-is-customer-service/ ">What is Customer
1393 Service?</a></li>
1394 <li><a href=" https://www.oracle.com/erp/what-is-erp/">What is ERP?</a></li>
1395 <li><a
1396 href=" https://www.oracle.com/cx/marketing/automation/what-is-marketing-automation/ ">What
1397 is Marketing Automation?</a></li>
1398 <li><a href="https://www.oracle.com/erp/what-is-procurement/ ">What is Procurement?</a></li>
1399 <li><a
1400 href="https://www.oracle.com/human-capital-management/talent-management/what-is-talent-management/ ">What
1401 is Talent Management?</a></li>
1402 <li><a
1403 href=" https://www.oracle.com/cloud/compute/virtual-machines/what-is-virtual-machine/ ">What
1404 is VM?</a></li>
1405 </ul>
1406 </div>
1407 </div>
1408 <div class="u10w2">
1409 <div class="u10w3">
1410 <h5>What's New</h5>
1411 <ul>
1412 <li><a
1413 href="https://www.oracle.com/cloud/free/?source=:ow:o:h:nav:050120SiteFooter&intcmp=:ow:o:h:nav:050120SiteFooter">Try
1414 Oracle Cloud Free Tier</a></li>
1415 <li><a href="https://www.oracle.com/solutions/green/">Oracle Sustainability</a></li>
1416 <li><a href="https://www.oracle.com/corporate/covid-19.html ">Oracle COVID-19 Response</a>
1417 </li>
1418 <li><a href="https://www.oracle.com/sailgp/">Oracle and SailGP</a></li>
1419 <li><a href="https://www.oracle.com/premier-league/">Oracle and Premier League</a></li>
1420 <li><a href="https://www.oracle.com/redbullracing/">Oracle and Red Bull Racing Honda</a>
1421 </li>
1422 </ul>
1423 </div>
1424 </div>
1425 <div class="u10w2">
1426 <div class="u10w3">
1427 <h5>Contact Us</h5>
1428 <ul>
1429 <li><a href="tel:18006330738">US Sales 1.800.633.0738</a></li>
1430 <li><a href="https://www.oracle.com/corporate/contact/">How can we help?</a></li>
1431 <li><a href="https://go.oracle.com/subscriptions">Subscribe to Oracle Content</a></li>
1432 <li><a
1433 href="https://www.oracle.com/cloud/free/?source=:ow:o:h:nav:050120SiteFooter&intcmp=:ow:o:h:nav:050120SiteFooter">Try
1434 Oracle Cloud Free Tier</a></li>
1435 <li><a href="https://www.oracle.com/events/">Events</a></li>
1436 <li><a href="https://www.oracle.com/news/" data-lbl="news-events:newsroom">News</a></li>
1437 </ul>
1438 </div>
1439 </div>
1440 <div class="u10w4">
1441 <hr />
1442 </div>
1443
1444 <div class="u10w5 ">
1445 <ul class="u10-links u10w10">
1446 <li><a href="https://www.oracle.com/legal/copyright.html" data-lbl="copyright">© 2022 Oracle</a></li>
1447
1448 <li><a data-lbl="privacy"
1449 href="https://www.oracle.com/legal/privacy/">Privacy</a><span>/</span><a
1450 data-lbl="do-not-sell-my-info"
1451 href="https://www.oracle.com/legal/privacy/privacy-choices.html">Do Not Sell My Info</a>
1452 </li>
1453 <li>
1454 <div id='teconsent'> </div>
1455 </li>
1456 <li><a href="https://www.oracle.com/legal/privacy/privacy-policy.html#advertising"
1457 data-lbl="ad-choices">Ad Choices</a></li>
1458 <li><a href="https://www.oracle.com/corporate/careers/" data-lbl="careers">Careers</a></li>
1459 </ul>
1460
1461 </div>
1462 </div>
1463
1464 </div>
1465 <!-- /U10v6 -->
1466
1467
1468 </div>
1469 <script type="text/javascript" src="https://www.oracle.com/us/assets/metrics/ora_compendiumblogs.js"></script>
1470 <script type="text/javascript" src="https://www.oracle.com/assets/truste-oraclelib.js"></script>
1471 <script async="async" type="text/javascript"
1472 src="//consent.trustarc.com/notice?domain=oracle.com&c=teconsent&js=bb¬iceType=bb&text=true>m=1&cdn=1&pcookie"
1473 crossorigin=""></script>
1474 <script type="text/javascript" src="../_cache_8b25/siteinfo-common.js" charset="utf-8"></script><script type="text/javascript" src="../siteinfo-dynamic.js"></script>
1475 <script src="../_cache_8b25/_sitesclouddelivery/renderer/renderer.js"></script>
1476
1477
1478
1479
1480 <script src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/js/blogs-script.js"></script>
1481 <script src="../_cache_8b25/_themesdelivery/Blogs-New-Theme/assets/js/oracle-script.js"></script>
1482
1483 <!-- Avoid FOUC issue in FF with async loading of style sheets -->
1484 <style>
1485 body {
1486 opacity: 1;
1487 }
1488 </style>
1489
1490 <script type="text/javascript">
1491 $(document).ready(function () {
1492 $('a[data-lbl="copyright"]').html("© " + new Date().getFullYear() +" Oracle " );
1493
1494 });
1495 </script>
1496 <!--DTM/Launch embed code - Footer -->
1497
1498 </body>
1499
1500