Hi
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Soby Mathew via TF-A Sent: 06 January 2020 12:34 To: Olivier Deprez Olivier.Deprez@arm.com; tf-a@lists.trustedfirmware.org; Sheetal Tigadoli sheetal.tigadoli@broadcom.com Cc: nd nd@arm.com Subject: Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's
Hi All,
I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console.
Please let me your thoughts on this.
Link to this question on Phabricator - https://developer.trustedfirmware.org/T624
Thanks Sheetal
As Sandrine said in Phabricator, the reason was simply to leave space between the levels to allow adding intermediate levels without breaking compatibility. Compatibility was a possible concern if external tools used the log level and you only rebuilt some of the TF-A components (components could end up using different values). However, I suspect the actual level value is never emitted in practice (just the text prefix) so this may not be a real concern.
Hi Sheetal I didn't quite get reason for the optimization from multiples of 10 to consecutive numbers. The mod operation you refer to are assertions which will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that there is a single divide by 10 operation within the default implementation of plat_log_get_prefix().
If the logging utility is considered performance critical, removing the single divide by 10 will not result in any gain. Usually the bottleneck for logs are UART baudrates and the CPU spends most of time spinning in a wait loop for UART to be free. Hence I don't see any need for change for log levels macro if the intent is performance optimization.
+1. Unless there's an actual performance gain, this sounds like an unnecessary change.
Dan.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-a@lists.trustedfirmware.org