[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342741437.3010.275.camel@misato.fc.hp.com>
Date: Thu, 19 Jul 2012 17:43:57 -0600
From: Toshi Kani <toshi.kani@...com>
To: shuah.khan@...com
Cc: lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, bhelgaas@...gle.com,
isimatu.yasuaki@...fujitsu.com, liuj97@...il.com,
srivatsa.bhat@...ux.vnet.ibm.com, prarit@...hat.com,
imammedo@...hat.com, vijaymohan.pandarathil@...com,
shuahkhan@...il.com
Subject: Re: [PATCH 1/4] ACPI: Add acpi_pr_<level>() interfaces
On Thu, 2012-07-19 at 16:32 -0600, Shuah Khan wrote:
> On Thu, 2012-07-19 at 14:51 -0600, Toshi Kani wrote:
>
> > If your concern is actually a performance bottleneck in acpi_get_name()
> > you found in the code, you should report it to the ACPI CA team.
>
> I have tried my best to get you to understand the problems in bigger
> picture your patch set can exacerbate. Looking to somebody else to fix
> the problems doesn't help. It doesn't look like we can come to an
> agreement here, we just have to agree to disagree.
I am not asking someone to fix it. I tried my best to explain that
acpi_get_name() does not lead any performance issue when it is called in
the error paths of ACPI drivers, and why we have to call it to obtain an
object path info for error analysis. If you still believe there is a
performance issue in calling acpi_get_name() under this context, please
help us understand where the performance bottleneck is in the code. (I
hope you just concerned it because it has "acpi_" prefix...) I will then
work on the issue with the ACPI CA team.
Thanks,
-Toshi
> caio,
> -- Shuah
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists