public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* ACPI owner_id limit too low
@ 2005-12-08 18:21 Alex Williamson
  2005-12-08 20:23 ` Carl-Daniel Hailfinger
  0 siblings, 1 reply; 6+ messages in thread
From: Alex Williamson @ 2005-12-08 18:21 UTC (permalink / raw)
  To: len.brown; +Cc: linux-kernel, acpi-devel


   We've found recently that it's not very hard to bump into the limit
of the number of owner_ids that the ACPI subsystem can provide.  This is
not because of leaks or complicated method execution, but simply because
our ACPI namespace is describing a complicated system and includes a
large number of SSDT tables.  We end up using far more than half the
owner_ids statically allocated for these tables.  The ACPI subsystem has
a limit of 256 ACPI tables, but we'd have a hard time getting within an
order of magnitude of that number and still have enough owner_ids
available for method execution.  I hear rumor that the next CA release
increases this limit, but given that the in kernel CA revision often
lags by several months, I'm wondering if we can bump up this limit in
the interim.  Doubling the limit to 64 is a sufficient short term fix
and a fairly trivial patch, maybe even something that could go in before
2.6.15.  Len, could we do something like the below patch to give us a
little more reasonable limit?  We could switch to a bitmap too, but
given how close the next kernel is to release this is less impact.
Thanks,

	Alex


Signed-off-by: Alex Williamson <alex.williamson@hp.com>
---

diff -r 03055821672a drivers/acpi/utilities/utmisc.c
--- a/drivers/acpi/utilities/utmisc.c	Mon Dec  5 01:00:10 2005
+++ b/drivers/acpi/utilities/utmisc.c	Wed Dec  7 14:55:58 2005
@@ -84,14 +84,14 @@
 
 	/* Find a free owner ID */
 
-	for (i = 0; i < 32; i++) {
-		if (!(acpi_gbl_owner_id_mask & (1 << i))) {
+	for (i = 0; i < 64; i++) {
+		if (!(acpi_gbl_owner_id_mask & (1UL << i))) {
 			ACPI_DEBUG_PRINT((ACPI_DB_VALUES,
-					  "Current owner_id mask: %8.8X New ID: %2.2X\n",
+					  "Current owner_id mask: %16.16lX New ID: %2.2X\n",
 					  acpi_gbl_owner_id_mask,
 					  (unsigned int)(i + 1)));
 
-			acpi_gbl_owner_id_mask |= (1 << i);
+			acpi_gbl_owner_id_mask |= (1UL << i);
 			*owner_id = (acpi_owner_id) (i + 1);
 			goto exit;
 		}
@@ -106,7 +106,7 @@
 	 */
 	*owner_id = 0;
 	status = AE_OWNER_ID_LIMIT;
-	ACPI_REPORT_ERROR(("Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT\n"));
+	ACPI_REPORT_ERROR(("Could not allocate new owner_id (64 max), AE_OWNER_ID_LIMIT\n"));
 
       exit:
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);
@@ -123,7 +123,7 @@
  *              control method or unloading a table. Either way, we would
  *              ignore any error anyway.
  *
- * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 32
+ * DESCRIPTION: Release a table or method owner ID.  Valid IDs are 1 - 64
  *
  ******************************************************************************/
 
@@ -140,7 +140,7 @@
 
 	/* Zero is not a valid owner_iD */
 
-	if ((owner_id == 0) || (owner_id > 32)) {
+	if ((owner_id == 0) || (owner_id > 64)) {
 		ACPI_REPORT_ERROR(("Invalid owner_id: %2.2X\n", owner_id));
 		return_VOID;
 	}
@@ -158,8 +158,8 @@
 
 	/* Free the owner ID only if it is valid */
 
-	if (acpi_gbl_owner_id_mask & (1 << owner_id)) {
-		acpi_gbl_owner_id_mask ^= (1 << owner_id);
+	if (acpi_gbl_owner_id_mask & (1UL << owner_id)) {
+		acpi_gbl_owner_id_mask ^= (1UL << owner_id);
 	}
 
 	(void)acpi_ut_release_mutex(ACPI_MTX_CACHES);
diff -r 03055821672a include/acpi/acglobal.h
--- a/include/acpi/acglobal.h	Mon Dec  5 01:00:10 2005
+++ b/include/acpi/acglobal.h	Wed Dec  7 14:55:58 2005
@@ -211,7 +211,7 @@
 ACPI_EXTERN u32 acpi_gbl_rsdp_original_location;
 ACPI_EXTERN u32 acpi_gbl_ns_lookup_count;
 ACPI_EXTERN u32 acpi_gbl_ps_find_count;
-ACPI_EXTERN u32 acpi_gbl_owner_id_mask;
+ACPI_EXTERN u64 acpi_gbl_owner_id_mask;
 ACPI_EXTERN u16 acpi_gbl_pm1_enable_register_save;
 ACPI_EXTERN u16 acpi_gbl_global_lock_handle;
 ACPI_EXTERN u8 acpi_gbl_debugger_configuration;

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: ACPI owner_id limit too low
@ 2005-12-08 23:18 Moore, Robert
  0 siblings, 0 replies; 6+ messages in thread
From: Moore, Robert @ 2005-12-08 23:18 UTC (permalink / raw)
  To: Alex Williamson
  Cc: Brown, Len, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

If you felt ambitious, you could take a look at making the change to not
allocate owner IDs for the static tables (tables that cannot be
unloaded). This would really take the pressure off the Owner ID.
Requires a change to the shutdown mechanism to make sure that the
namespace is completely deleted.


> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson-VXdhtT5mjnY@public.gmane.org]
> Sent: Thursday, December 08, 2005 2:21 PM
> To: Moore, Robert
> Cc: Brown, Len; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; acpi-
> devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: RE: [ACPI] ACPI owner_id limit too low
> 
> On Thu, 2005-12-08 at 14:03 -0800, Moore, Robert wrote:
> > We have increased the number of owner IDs to 255 in the most recent
> > version of ACPICA, 20051202. This should hit Linux soon.
> >
> > Additionally, we plan to conserve OwnerIDs by not using them for
tables
> > that can never be unloaded, to be implemented in a future release.
> > However, 255 Ids should be plenty for now.
> >
> > Here is the text from the release memo:
> >
> > Increased the number of available Owner Ids for namespace object
> > tracking from 32 to 255. This should eliminate the OWNER_ID_LIMIT
> > exceptions seen on some machines with a large number of ACPI tables
> > (either static or dynamic).
> 
> Hi Bob,
> 
>    Sorry if I wasn't clear, I'm worried about what happens in the
> interim.  The problem will be fixed in ACPICA 20051202, but we have at
> least one, likely two stable kernels that will be tagged before that
> ACPICA version hits the upstream kernel.  We can hit the owner_id
limit
> fairly easily on a few development systems.  How many stable kernels
do
> we want out in the wild with such a low owner_id limit?  Bumping it up
> to 64, while not ideal, is sufficient for our current usage, and I
think
> the patch is trivial enough that it could be included quickly.
Thanks,
> 
> 	Alex
> 
> --
> Alex Williamson                             HP Linux & Open Source Lab



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: ACPI owner_id limit too low
@ 2005-12-09  4:32 Brown, Len
  0 siblings, 0 replies; 6+ messages in thread
From: Brown, Len @ 2005-12-09  4:32 UTC (permalink / raw)
  To: Alex Williamson; +Cc: linux-kernel, acpi-devel

Hi Alex,

Yes, ACPICA 20051202 upped the limit to 255 from 32,
but as it is mixed in with some other large changes,
I'm thinking I'll that release soak until the opening
of 2.6.17.

So if you need a higher limit in 2.6.15 we can
push this simpler patch, of if Linus shuts down
2.6.15 when we returns we can send it to stable to
get into 2.6.15.*

thanks,
-Len

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: ACPI owner_id limit too low
@ 2005-12-21  3:52 Brown, Len
  0 siblings, 0 replies; 6+ messages in thread
From: Brown, Len @ 2005-12-21  3:52 UTC (permalink / raw)
  To: Alex Williamson, Carl-Daniel Hailfinger
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

applied to acpi-test

thanks,
-Len 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-12-21  3:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-08 18:21 ACPI owner_id limit too low Alex Williamson
2005-12-08 20:23 ` Carl-Daniel Hailfinger
     [not found]   ` <4398963D.8040207-hi6Y0CQ0nG0@public.gmane.org>
2005-12-08 20:36     ` Alex Williamson
  -- strict thread matches above, loose matches on Subject: below --
2005-12-08 23:18 Moore, Robert
2005-12-09  4:32 Brown, Len
2005-12-21  3:52 Brown, Len

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox