(unknown),

(unknown),

[Chen Gong]

[PATCH] eliminate the usage of printk_ratelimit

It is a simple printk limit patch based on latest acpi-test tree

[PATCH] eliminate the usage of printk_ratelimit

[Chen Gong]

To avoid messages to be suppressed, use __ratelimit to
substitute printk_ratelimit.

Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
---
 drivers/acpi/apei/ghes.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 51905d0..29d38ad 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -180,13 +180,15 @@ static int ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
 static int ghes_read_estatus(struct ghes *ghes, int silent)
 {
 	struct acpi_hest_generic *g = ghes->generic;
+	/* Not more than 2 messages every 5 seconds */
+	static DEFINE_RATELIMIT_STATE(ratelimit, 5*HZ, 2);
 	u64 buf_paddr;
 	u32 len;
 	int rc;
 
 	rc = acpi_atomic_read(&buf_paddr, &g->error_status_address);
 	if (rc) {
-		if (!silent && printk_ratelimit())
+		if (!silent && __ratelimit(&ratelimit))
 			pr_warning(FW_WARN GHES_PFX
 "Failed to read error status block address for hardware error source: %d.\n",
 				   g->header.source_id);
-- 
1.7.3.1.120.g38a18

Re: [PATCH] eliminate the usage of printk_ratelimit

[Len Brown]

On Wed, 15 Dec 2010, Chen Gong wrote:

> To avoid messages to be suppressed, use __ratelimit to
> substitute printk_ratelimit.
> 
> Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
> ---
>  drivers/acpi/apei/ghes.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 51905d0..29d38ad 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -180,13 +180,15 @@ static int ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
>  static int ghes_read_estatus(struct ghes *ghes, int silent)
>  {
>  	struct acpi_hest_generic *g = ghes->generic;
> +	/* Not more than 2 messages every 5 seconds */
> +	static DEFINE_RATELIMIT_STATE(ratelimit, 5*HZ, 2);
>  	u64 buf_paddr;
>  	u32 len;
>  	int rc;
>  
>  	rc = acpi_atomic_read(&buf_paddr, &g->error_status_address);
>  	if (rc) {
> -		if (!silent && printk_ratelimit())
> +		if (!silent && __ratelimit(&ratelimit))

So you want to change 10 messages/5s into 2 messages/5s?

That isn't a very big change.

Is using ratelimit better than using printk_once()?

-Len

>  			pr_warning(FW_WARN GHES_PFX
>  "Failed to read error status block address for hardware error source: %d.\n",
>  				   g->header.source_id);
> -- 
> 1.7.3.1.120.g38a18

Re: [PATCH] eliminate the usage of printk_ratelimit

[Chen Gong]

于 12/17/2010 2:27 PM, Len Brown 写道:
> On Wed, 15 Dec 2010, Chen Gong wrote:
>
>> To avoid messages to be suppressed, use __ratelimit to
>> substitute printk_ratelimit.
>>
>> Signed-off-by: Chen Gong<gong.chen@linux.intel.com>
>> ---
>>   drivers/acpi/apei/ghes.c |    4 +++-
>>   1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 51905d0..29d38ad 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -180,13 +180,15 @@ static int ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
>>   static int ghes_read_estatus(struct ghes *ghes, int silent)
>>   {
>>   	struct acpi_hest_generic *g = ghes->generic;
>> +	/* Not more than 2 messages every 5 seconds */
>> +	static DEFINE_RATELIMIT_STATE(ratelimit, 5*HZ, 2);
>>   	u64 buf_paddr;
>>   	u32 len;
>>   	int rc;
>>
>>   	rc = acpi_atomic_read(&buf_paddr,&g->error_status_address);
>>   	if (rc) {
>> -		if (!silent&&  printk_ratelimit())
>> +		if (!silent&&  __ratelimit(&ratelimit))
>
> So you want to change 10 messages/5s into 2 messages/5s?
>
> That isn't a very big change.

No, it is because printk_ratelimit shares ratelimiting state
with all other *unrelated* printk_ratelimit() callsites.

>
> Is using ratelimit better than using printk_once()?
>
> -Len
>
>>   			pr_warning(FW_WARN GHES_PFX
>>   "Failed to read error status block address for hardware error source: %d.\n",
>>   				   g->header.source_id);
>> --
>> 1.7.3.1.120.g38a18
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html