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

Re: [PATCH 21/36] xen/common: add colored allocator initialization


  • To: Marco Solieri <marco.solieri@xxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 9 Mar 2022 15:58:42 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=2DDYZ1HkK7B0NjXMi72+t7QXaFJlZEG9PQd31XCZQ2Y=; b=Z4wF0S7WiHFbjdIMAN7jEcPrTUgiz1lT+chieXngBGtPXP/NK5AH7xbBd986wLxjHOpGhcv9COemBZeT98EwtrlY6SBxh0jQExrPaUsuDpYU9MJvzi8RTCruuJE6ezKzFwnh/jW2cCsBeQ+8/HsFkpDV1Q9oLiUdVfrkpNp0kCZYGH69XLx9EWTwtShBV97DmNtglxqYxBNjIW/iyFgH9ihOZs/OaaSw6ITr20b5hkoynRT+NBjqTUG8PrPDqhJTQ9GI1tCkfD8jpcUy1WLpeRs7HXlXrzcYLCMnoqSsGJO7LlmzoWD20c5u70KICxXPLHTqzp76gMppFXtPfvsUdw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WDY1vvFG9ggq0m5hdGKvmjNSctthLR/PuUmv+3icxVxXMIAW9jgqWdFCsLGgQnPoStFHuTNz3dN6zVP6TIlfmUbeVsRY9Zcw7eP2b8D180Y6nP7UkYTb7L3TeEy8rFiByCM1wy8jWz9rzUg3OtYUUuqiI7ofy9/un+9QZe4h+OeAnfip+oUrvVc8PKCO+/GCgD+9Pfcj9WySOcRenTvMZWaZ/mFWhEaetGHA4Cd+uqzPuOo7L5xMx+L77jr+myqsiuVyCKZYg1ityi6ywTFyx9QuUNkTQAKlKHkeRXlEuqxZ+GGSq2up4iHtu0+xIHhlCGqAQcPKQSV79ddLAlA7Aw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Marco Solieri <marco.solieri@xxxxxxxxxx>, Andrea Bastoni <andrea.bastoni@xxxxxxxxxxxxxxx>, Luca Miccio <lucmiccio@xxxxxxxxx>, Luca Miccio <206497@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 09 Mar 2022 14:58:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.03.2022 18:46, Marco Solieri wrote:
> From: Luca Miccio <lucmiccio@xxxxxxxxx>
> 
> Initialize colored heap and allocator data structures. It is assumed
> that pages are given to the init function is in ascending order.

I don't think this is a good assumption to make.

> To
> ensure that, pages are retrieved from bootmem_regions starting from the
> first one. Moreover, this allows quickly insertion of freed pages into
> the colored allocator's internal data structures -- sorted lists.

I wouldn't call insertion by linear scan "quick", to be honest.

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2154,11 +2154,26 @@ void __init end_boot_allocator(void)
>              break;
>          }
>      }
> -    for ( i = nr_bootmem_regions; i-- > 0; )
> +
> +    for ( i = 0; i < nr_bootmem_regions; i++ )
>      {
>          struct bootmem_region *r = &bootmem_region_list[i];
> -        if ( r->s < r->e )
> -            init_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);
> +
> +        /*
> +         * Find the first region that can fill the buddy allocator memory
> +         * specified by buddy_required_size.
> +         */

Why would all of this memory need to come from a single region? And
why would any region - regardless of address - be okay?

> +        if ( buddy_required_size && (r->e - r->s) >
> +            PFN_DOWN(buddy_required_size) )

I think >= will do here?

Also - nit: Indentation.

> +        {
> +            init_heap_pages(mfn_to_page(_mfn(r->s)),
> +                PFN_DOWN(buddy_required_size));

And again - indentation.

> +            r->s += PFN_DOWN(buddy_required_size);
> +            buddy_required_size = 0;
> +        }
> +
> +        init_col_heap_pages(mfn_to_page(_mfn(r->s)), r->e - r->s);

Judging from this, buddy_required_size can actually be __initdata in
the previous patch. Being able to spot such is another reason to not
split patches like this.

> @@ -2619,9 +2634,12 @@ int assign_pages(
>          page_set_owner(&pg[i], d);
>          smp_wmb(); /* Domain pointer must be visible before updating refcnt. 
> */
>          pg[i].count_info =
> -            (pg[i].count_info & (PGC_extra | PGC_reserved)) | PGC_allocated 
> | 1;
> +             (pg[i].count_info & (PGC_extra | PGC_reserved)) | PGC_allocated 
> | 1;

Why the change?

> @@ -2642,6 +2660,15 @@ struct page_info *alloc_domheap_pages(
>      unsigned int bits = memflags >> _MEMF_bits, zone_hi = NR_ZONES - 1;
>      unsigned int dma_zone;
>  
> +    /* Only Dom0 and DomUs are supported for coloring */
> +    if ( d && d->max_colors > 0 )
> +    {
> +        /* Colored allocation must be done on 0 order */
> +        if (order)

Nit: Missing blanks.

> @@ -2761,8 +2788,10 @@ void free_domheap_pages(struct page_info *pg, unsigned 
> int order)
>              scrub = 1;
>          }
>  
> -        free_heap_pages(pg, order, scrub);
> -    }
> +        if ( is_page_colored(pg) )
> +            free_col_heap_page(pg);
> +        else
> +            free_heap_pages(pg, order, scrub);}

Very interesting brace placement.

Jan




 


Rackspace

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