Ok, it is reasonable to keep CONFIG_ARM_UNWIND enabled when this option have no practical effect on performance or latency in kernel. So, keep it enabled. :-)
Martin 'Martix' Holec openmoko.cz / openmobility.cz 2011/3/8 Gennady Kupava <g...@bsdmn.com>: > Hi, > > 1. UNWIND do not influence performance, so enabling it should make no > harm (according to kernel doc, i trust em 99.9%). > 2. ability to get stack trace is widely accepted bare minimum of debug > info, this is info is _really_ (not like other hardly usable debugging > stuff were enabled earlier) invaluable for fixing and identifying > problems found. > > So, no reason remove both. It is even kind of switch in kernel config > turn on UNWIND -> FRAME_POINTER turns off. No affect on performance, add > ability to identify problem -> must have IMO. > > Gennady. > > В Втр, 08/03/2011 в 16:40 +0100, Martix пишет: >> Hi, >> thanks for comparison. >> I miss test with both CONFIG_ARM_UNWIND and CONFIG_FRAME_POINTER >> disabled, theoreticaly it could be faster. Anyway, why regular user >> (no developer, nor tester) needs to have CONFIG_ARM_UNWIND or >> CONFIG_FRAME_POINTER enabled? I suggest to disable CONFIG_ARM_UNWIND >> in stable kernel images. Stable I mean (in this case) kernel versions >> which is well tested in SHR-t and stable revisions of Qt Moko. >> >> Thanks Denis and Gennady. >> >> Martin 'Martix' Holec >> openmoko.cz/openmobility.cz >> >> >> 2011/3/8 Gennady Kupava <g...@bsdmn.com>: >> > Hi, list. >> > >> > Today I noticed the following change in SHR: >> > http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=1516588acd3c4b4dd4add71d06ab8ce0d1bafa02 >> > (by Denis 'GNUtoo' Carikli <gnu...@no-log.org>) and decided to lmbench it. >> > >> > Here are results: http://www.bsdmn.com/lmbench/unwind_summary.txt >> > >> > You can see comparison of: >> > >> > 34def -> kernel with CONFIG_FRAME_POINTER >> > unwind -> kernel with CONFIG_ARM_UNWIND >> > default -> for reference, old debugging kernel >> > >> > The unwind option provide clear benefit of 5%-10% in almost every area. >> > >> > Nice spot Denis! >> > >> > Gennady. >> > >> > >> > _______________________________________________ >> > Openmoko community mailing list >> > community@lists.openmoko.org >> > http://lists.openmoko.org/mailman/listinfo/community >> > > > > _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community