From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gianluca Guida Subject: Re: vnif socket buffer mistaken for pagetable page causes major performance problem Date: Mon, 08 Jun 2009 10:11:15 +0100 Message-ID: <4A2CD5B3.4090700@eu.citrix.com> References: <2ee9aac0-0772-4306-a9e5-bf711cf2c2d8@default> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2ee9aac0-0772-4306-a9e5-bf711cf2c2d8@default> 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: "herbert.van.den.bergh@oracle.com" , "Xen-Devel (E-mail)" List-Id: xen-devel@lists.xenproject.org Hi, Sorry for the late reply, Dan Magenheimer wrote: > A recent posting reminded me of this and, though the > information is a bit vague, someone familiar with the > shadow code might know just where to look to fix this, > hopefully in time for 3.4 (if its not already fixed). > > One of our performance experts discovered a strange > major network performance hit seen only under certain > circumstances, IIRC mostly in HVM but sometimes in > PV when migrating. > > With some help from Intel, it was determined that > the heuristics used by shadow paging to determine > whether a guest is modifying a pagetable page were > getting fooled by the access pattern used by the > code that copies data into a newly allocated socket > buffer. As a result, many unnecessary vmenter/vmexits > were happening. > > The workaround was to preallocate all socket buffer > memory. > > That's all I've got, but we can try to answer questions > if this isn't already a known fixed problem. Can you be a little more specific about what is the performance loss, in what workload, and what heuristic you found to be wrong in this case? Thanks, Gianluca