linux-kernel - Re: [PATCH 2/9] ext4: Use pr_fmt and pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F6B5B1E.9090402@suse.cz>
Date:	Thu, 22 Mar 2012 18:02:22 +0100
From:	Jiri Slaby <jslaby@...e.cz>
To:	Joe Perches <joe@...ches.com>
CC:	Jiri Slaby <jirislaby@...il.com>, Ted Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ext4: Use pr_fmt and pr_<level>

On 03/20/2012 10:46 AM, Joe Perches wrote:
> On Tue, 2012-03-20 at 10:25 +0100, Jiri Slaby wrote:
>> On 03/20/2012 10:21 AM, Joe Perches wrote:
>>> the ath5k pr_ conversion patches are to
>>> standardize prefixes and to reduce code size by
>>> centralizing tests.
>>
>> What is the "standard" prefix?
> 
> KBUILD_MODNAME

Instead, we should switch as many printks to dev_* and similar as
possible, right? They are standard and provide a good interface for
extensions: one has a device to work with. This is something what pr_*
does not offer. For that reason it's not worth it.

>>> https://lkml.org/lkml/2012/3/18/121
>>> https://lkml.org/lkml/2012/3/18/123
>>> https://lkml.org/lkml/2012/3/18/124
>>> I happen to like 30K/10+% code size reductions.
>> Obvious question: what speed reduction does this bring?
> 
> Anyone looking for speed impacts in logging
> messages is looking in the wrong place.

Ok, I finally found some time to look into the changes properly. I was
confused by Adrian's note that you moved a debug check to an external
function. But that is not true.

> btw: it's effectively 0.

Frankly, moving the debug code to a separate function should make the
code rather faster. By moving the unlikely code out of the instruction
cache.

thanks,
-- js suse labs

--
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/