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

Re: [Xen-devel] [PATCH]acpi: enlarge NUM_FIXMAP_ACPI_PAGES from 4 to 5


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: "Zhangbo (Oscar)" <oscar.zhangbo@xxxxxxxxxx>
  • Date: Thu, 11 May 2017 06:45:35 +0000
  • Accept-language: zh-CN, en-US
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 11 May 2017 06:46:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AdLEgk4v/0Klkhg9TPax4OWLlRXTKgEsUjAAADuPbtA=
  • Thread-topic: [Xen-devel] [PATCH]acpi: enlarge NUM_FIXMAP_ACPI_PAGES from 4 to 5

>> --- a/xen/include/xen/acpi.h
>> +++ b/xen/include/xen/acpi.h
>> @@ -43,7 +43,7 @@
>>   * Fixmap pages to reserve for ACPI boot-time tables (see asm-x86/fixmap.h
>or
>>   * asm-arm/config.h)
>>   */
>> -#define NUM_FIXMAP_ACPI_PAGES  4
>> +#define NUM_FIXMAP_ACPI_PAGES  5
>
>Well, this is the kind of fix I don't really like: You make things work for
>you without thinking about others. If you found 4 pages aren't
>enough, how likely is it that soon someone will find 5 aren't enough
>either? IOW, short of eliminating the fixed upper bound altogether,
>you should at least add some slack for the foreseeable future. For
>this it may also help to estimate the theoretical upper limit of SRAT
>(and perhaps other affected tables) for systems currently around
>plus, again, some slack. As you may have concluded already it
>would therefore also have helped if you had indicated what size a
>system you see this relatively large SRAT on.
>
>Jan

Thanks, Jan, I'm checking the proper number, and patch v2 is on its way.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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