From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gianluca Guida Subject: Re: [PATCH] Add new location of Linux direct-map to theplaces to look for writable mappings Date: Fri, 12 Sep 2008 21:32:56 +0100 Message-ID: <48CAD1F8.2090507@eu.citrix.com> References: <46f44832-0241-48ff-a6d2-d278003d42a1@default> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: George Dunlap , Ian Pratt , xen-devel mailing list List-Id: xen-devel@lists.xenproject.org Sorry for the double-quote, I never received bizarrely Dan's email and I have only Ian's answer. >> I haven't even looked at this code so sorry for my >> possibly naive comment, but isn't this just asking for >> trouble to hardcode constants that apply to specific >> OS's? Isn't there a way to "sense" that this address is >> used a lot and add it to a dynamic list that can be >> checked? Else sooner or later some user is going to say >> "I tried Xen on xxx OS and performance sucked and it >> was fine on (unnamed virtualization platform)". But that >> user might not be as diligent about reporting to >> xen-devel as Todd was. I would just like to note that this disastrous benchmark result was due to two consecutive problems, the OS heuristic being only a secondary issue. Usually, removing write access to an out-of-sync page shouldn't need at all the OS heuristic guessing, since it is a very frequent operation and that would affect performances (as we all have seen). Fixup tables exist exactly for this purpose, acting basically as reverse map for writable mappings of pagetables. What was happening is that the fixup tables were failing, thus the research of the writable mappings was falling back to guest heuristic. This is bad per se, but it was working well enough until 2.6.27. So, while I agree that having hard-coded addresses into the hypervisor is not nice, in case of failure of this mechanism the results shouldn't be as bad as the one we've seen. That was all my fault. :) Thanks, Gianluca