<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for greglinwood</title><link>http://disqus.com/by/greglinwood/</link><description></description><atom:link href="http://disqus.com/greglinwood/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 22 Jul 2009 08:44:27 -0000</lastBuildDate><item><title>Re: Large Pages and SQL Server</title><link>http://jasonmassie.com/archive/2009/07/large-pages-and-sql-server/#comment-13105366</link><description>&lt;p&gt;Sure - but I'm just pointing out that I think it's not a great idea to leave write-access open to kernel memory, purely for the minor perf improvements large pages might bring. If system stability isn't enough of a reason, security should be.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">greglinwood</dc:creator><pubDate>Wed, 22 Jul 2009 08:44:27 -0000</pubDate></item><item><title>Re: Large Pages and SQL Server</title><link>http://jasonmassie.com/archive/2009/07/large-pages-and-sql-server/#comment-13004581</link><description>&lt;p&gt;You want to be 100% sure of your device drivers before using large pages b/c whilst it's a perf improvement option, it also increases the ability for device drivers to corrupt the o/s (larger pages are marked as read / write protection vs smaller pages enabling kernel code to be marked as read only protection exclusively).&lt;/p&gt;&lt;p&gt;Hence, it's definitely good for benchmarking on very carefully controlled hardware / drivers, but not good for general population use "in the wild" on commodity hardware.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">greglinwood</dc:creator><pubDate>Tue, 21 Jul 2009 13:14:07 -0000</pubDate></item></channel></rss>