[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v1 3/5] xen/arm: unpopulate memory when domain on static allocation


  • To: Julien Grall <julien@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Penny Zheng <Penny.Zheng@xxxxxxx>
  • Date: Sat, 2 Apr 2022 10:16:21 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gDq3jqDKdD2znKf6w6nvM2pa6p9pftFfu0HJJoqqYjo=; b=H9v6rbOgoU4/D5AGRy+2mqnFfh/BdHWYa0qvLw0RdVwVUluomqWq/sL97790d/x0wJcwDQuKtwQ4XDxOmLVMkthX6dqnzYWHFIbktVF9uS5X+SxZL5d7UBDRGn5y23UZz7YFdJhZcq/4lKpkP3UGuIWZ+oDt0NE67QUz/NiNr1ETp6MGYArRYZV9MrANOpsoGiZj7VhCW6ndHHEwtFYaHAExLr/35Qls+lOsYE1jhyfJ5wRiKDjRm26Yng0i/t/kSMj17kG8gXOqC8rVxWnWKUePLjcAacmDrNOjKUdVua/XfwZ04fwnFUfzXKxy5/ZPWEtZJcFELzKu9MNkjOc0zw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TcNbVMLBlKekgN07hc5+SaSWyZBnKwFL6X0b5apuEmWVqRqZs9PfW81idtRgXsH4SdF+1jGFggvUSD3GSFaeswk4Ue2jgSFeJf+V8onDyb7WCHwLDbqzgEeUSzdEJa67C5ahZj/eurIdiQb454nbWD9rvrSvzIw/WYujpvKFSJRpqYgS6I5se3K10kp3dyViCqbd+bau9yz0uLy85cSH9R30kg49t0mq8FXUe818bIxk4kVpiRRRbfUj1FK3Co2WXumdE/0QboVv04heWYzhAjgjeYLLU3LmolwD3RpK9Q4UUZPLOcWl+NozZAVnHWsIXlUbdTf/AdolSphBYFP4OA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 02 Apr 2022 10:17:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYRBnkeXnYvoANH0WdfY8GUNrlN6zXr5KAgAEgZ0CAAENNAIAAARVQgAJXEYCAANs8kA==
  • Thread-topic: [PATCH v1 3/5] xen/arm: unpopulate memory when domain on static allocation

Hi Julien and Jan

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Saturday, April 2, 2022 2:54 AM
> To: Penny Zheng <Penny.Zheng@xxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Henry Wang <Henry.Wang@xxxxxxx>;
> Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap
> <george.dunlap@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei
> Liu <wl@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v1 3/5] xen/arm: unpopulate memory when domain on
> static allocation
> 
> Hi Penny,
> 
> On 31/03/2022 11:30, Penny Zheng wrote:
> > Another reason I want to keep page allocated is that if putting pages
> > in resv_page_list upon dropping the last ref, we need to do a lot
> > things on pages to totally let it free, like set its owner to NULL,
> > changing page state from in_use to free, etc.
> This is not only about optimization here. Bad things can happen if you let a
> page in state free that is not meant to be used by the buddy allocator (e.g. 
> it
> was reserved for static memory).
> 
> I discovered it earlier this year when trying to optimize
> init_heap_pages() for Live-Update. It was quite hard to debug because the
> corruption very rarely happened. So let me explain it before you face the same
> issue :).
> 
> free_heap_pages() will try to merge the about-to-be-freed chunk with the
> predecessor and/or successor. To know if the page can be merged, the
> algorithm is looking at whether the chunk is suitably aligned (e.g. same
> order) and if the page is in state free.
> 
> AFAICT, the pages belonging to the buddy allocator could be right next to
> region reserved memory. So there is a very slim chance that
> free_heap_pages() may decide to merge a chunk from the static region with
> the about-to-be-free chunk. Nothing very good will ensue.
> 

Oh,,, that's a thousand true.
If the free static region is the buddy of the about-to-be-free chunk, current
code will merge the static region to the heap, which is unacceptable.

I'll fix it in this patch serie too and I'm also preferring option 1~

And for unpopulating memory on runtime, I'll do what Jan suggests,
adding a new logic of moving the page from d->page_list to
d->resv_page_list in arch_free_heap_page() for reserved pages. 

> Technically, this is already a bug in the already merged implementation of the
> static memory allocator.
> 
> I can see two ways to fix it:
>    1) Update free_heap_pages() to check whether the page has PGC_reserved
> set.
>    2) Use a different state for pages used by the static allocator.
> 
> So far my preference is leaning towards 1. But I would like to hear other
> opinions.
> 
> Cheers,
> 
> --
> Julien Grall

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.