From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Liu Subject: Re: A good way to speed up the xl destroy time(guest page scrubbing) Date: Mon, 08 Dec 2014 17:28:16 +0800 Message-ID: <54856F30.7000407@oracle.com> References: <546F1033.7030005@oracle.com> <54818221.1070804@oracle.com> <5481B1F6020000780004D24A@mail.emea.novell.com> <5484597A.507@oracle.com> <548570B2020000780004D99C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XxucM-0004EP-4S for xen-devel@lists.xenproject.org; Mon, 08 Dec 2014 09:28:34 +0000 In-Reply-To: <548570B2020000780004D99C@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com, ian.campbell@citrix.com, xen-devel List-Id: xen-devel@lists.xenproject.org On 12/08/2014 04:34 PM, Jan Beulich wrote: >>>> On 07.12.14 at 14:43, wrote: > >> On 12/05/2014 08:24 PM, Jan Beulich wrote: >>>>>> On 05.12.14 at 11:00, wrote: >>>> 5. Potential workaround >>>> 5.1 Use per-cpu list in idle_loop() >>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the >>>> per-cpu list and free back to heap_list. >>>> >>>> But Jan disagree with this solution: >>>> "You should really drop the idea of removing pages temporarily. >>>> All you need to do is make sure a page being allocated and getting >>>> simultaneously scrubbed by another CPU won't get passed to the >>>> caller until the scrubbing finished." >>> >>> So you don't mention any downsides to this approach. If there are >>> any, please name them. If there aren't, what's the reason not to >>> go this route? >> >> The reason was what you suggested was not very specific, I still have no >> idea how to implement a patch which can "make sure a page being >> allocated and getting simultaneously scrubbed by another CPU won't get >> passed to the caller until the scrubbing finished". > > The scrubbing code would need to mark the page, and the allocation > code would need to spin on such marked pages until the mark clears. > Thanks a lot, it's more clear! Then do you think it is safe to iterate the heap list without spin lock in the scrubbing code? Konrad also suggested a similar way which was skip marked pages(instead of spin) in the allocator, but I always got panic during page_list_for_each(&heap_list) in the scrubbing code if without locking the heap list. The panic happend in page_list_next(), I think that's because alloc/free path modified the heap list. -- Regards, -Bob