<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>LinuxEco &#187; Process Exchange</title>
	<atom:link href="http://linuxeco.com/?cat=51&#038;feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://linuxeco.com</link>
	<description>Linux Ecosystems, Linux Kernel Training, Kernel Education and Information Exchange, Linux Training</description>
	<lastBuildDate>Fri, 03 Aug 2012 18:36:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>LinuxEco Cross-Functional Quiz#1</title>
		<link>http://linuxeco.com/?p=406</link>
		<comments>http://linuxeco.com/?p=406#comments</comments>
		<pubDate>Mon, 30 Jan 2012 04:19:03 +0000</pubDate>
		<dc:creator>Anand</dc:creator>
				<category><![CDATA[Huge TLBs]]></category>
		<category><![CDATA[Linux Kernel Memory Management]]></category>
		<category><![CDATA[Linux kernel preemption]]></category>
		<category><![CDATA[Process Exchange]]></category>
		<category><![CDATA[Process Scheduling]]></category>
		<category><![CDATA[QUIZ]]></category>
		<category><![CDATA[Huge TLB Faults]]></category>
		<category><![CDATA[Linux Kernel Huge Pages]]></category>

		<guid isPermaLink="false">http://linuxeco.com/?p=406</guid>
		<description><![CDATA[OK&#8230; we have talked of Huge Pages in an earlier blog, and we have referred to Kernel Preemption. So we know now a Huge TLB Page can be GB sized&#8230;. and so therefore it stands to reason that a preemption is involved somewhere in  kernel API hugetlb_fault. Right ? GF-rins. SO &#8230; where is it [...]]]></description>
			<content:encoded><![CDATA[<p>OK&#8230; we have talked of Huge Pages in an earlier blog, and we have referred to Kernel Preemption.</p>
<p>So we know now a Huge TLB Page can be GB sized&#8230;. and so therefore it stands to reason that a preemption is involved somewhere in  kernel API <strong>hugetlb_fault</strong>. Right ? GF-rins.</p>
<p>SO &#8230; where is it that the Kernel is Possibly attempting a Preemption  on a page fault on a huge page ? More importantly, WHY would we do that ? Do we dig it now ? Haaaaaah ? Tell me then.</p>
<p>We explain these specific x86 and Linux Kernel features, concepts and more in detail in our class <a href="../?page_id=145"> Advanced Kernel Memory Management</a> , the second offering of which is to be made Corporate-direct. We suggest also   the <strong>Spring Session 2012 UCSC-Extension </strong> <a href="http://course.ucsc-extension.edu/modules/shop/index.html?action=section&amp;OfferingID=4940820&amp;SectionID=5270664"> Advanced Linux Kernel Programming</a></p>
<p>Please take note of these and other upcoming Linux kernel training sessions. As always, Feedback, Questions and Comments are appreciated and will be responded to.</p>
]]></content:encoded>
			<wfw:commentRss>http://linuxeco.com/?feed=rss2&#038;p=406</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Avoiding TLB Flushes on Context Switches on x86 Processors: The PCID</title>
		<link>http://linuxeco.com/?p=77</link>
		<comments>http://linuxeco.com/?p=77#comments</comments>
		<pubDate>Thu, 12 Jan 2012 05:13:07 +0000</pubDate>
		<dc:creator>Anand</dc:creator>
				<category><![CDATA[Linux Kernel Memory Management]]></category>
		<category><![CDATA[Linux Kernel x86]]></category>
		<category><![CDATA[Process Exchange]]></category>
		<category><![CDATA[Process Scheduling]]></category>
		<category><![CDATA[TLB Management]]></category>
		<category><![CDATA[Linux kernel]]></category>
		<category><![CDATA[PCID]]></category>
		<category><![CDATA[TLB Flushes]]></category>
		<category><![CDATA[x86 processord]]></category>
		<category><![CDATA[x86 processors]]></category>

		<guid isPermaLink="false">http://linuxeco.com/?p=77</guid>
		<description><![CDATA[CR3, CR4 are Control registers on x86 processors that are used configure and manage protected-mode functionality. These instructions may only be executed at CPL(Current Privilege) == 0 . i.e. in Kernel Mode. In the x86, linear addresses are translated by the TLB into Physical addresses (assuming Page Table Walks have been done prior to look [...]]]></description>
			<content:encoded><![CDATA[<div>CR3, CR4 are Control registers on x86 processors that are used configure and manage protected-mode functionality. These instructions may only be executed at CPL(Current Privilege) == 0 . i.e. in Kernel Mode.</div>
<div></div>
<div>In the x86, linear addresses are translated by the TLB into Physical addresses (assuming Page Table Walks have been done prior to look up etc).</div>
<div></div>
<div></div>
<div>A Cr3 load switches out Page Tables. In the Linux Kernel, it is executed during scheduling new process at context switch time (<strong>context_switch</strong>). Before the days of the <strong>PCID</strong> (see below), a load of CR3 flushed the TLB.</div>
<div></div>
<div></div>
<div>Avoiding TLB flushes on Loads of CR3 are key to avoiding performace hits  on context switches.  In other words, a processor really needs to facilitate the storage of multiple address spaces in the TLB across context switches.</div>
<div></div>
<div></div>
<div><strong>Process-context identifiers</strong> (<strong>PCID</strong>s) are a facility in x86 processors  by which a logical processor may cache information for multiple linear-address spaces in the TLB.</div>
<div></div>
<p>The processor may retain cached information when software switches to a different linear-address space with a different <strong>PCID</strong> e.g., by loading CR3.</p>
<div>When using entries in the TLBs and paging-structure caches to translate a linear address, a logical processor uses only those entries associated with the current <strong>PCID</strong></div>
<p>i.e. A PCID is a 12-bit identifier, and be thought of as a “Process-ID” for TLBs.</p>
<div>If CR4.PCIDE = 0 (but 17 of CR4), the current <strong>PCID</strong> is always 000H; otherwise, the current PCID is the value of bits 11:0 of CR3.</div>
<div></div>
<p>Non-zero <strong>PCIDs</strong> are enabled by setting the PCIDE flag (bit 17 of CR4). Rules do apply on enabling <strong>PCID</strong> on x86 processors. Caveats emptor. Naturally, restrictions on the operating system may apply to take advantage of this mechanism. Context switches that require isolation of Linear addresses between processes must be done  with care. And/or  linear addresses between processes with <strong>PCID</strong>&#8216;s enabled may overlap, and so will translations of Linear Addresses to Physical memory ! Ouch.</p>
<p>More on the implications of this for Linux will follow.</p>
<p>I  explain Linux Kernel concepts and more in my classes ( Advanced Linux Kernel Programming @UCSC-Extension, and also in other classes that I teach independently). As always, Feedback, Questions  and Comments are appreciated and will be responded to.</p>
]]></content:encoded>
			<wfw:commentRss>http://linuxeco.com/?feed=rss2&#038;p=77</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
