Philippe Gerum wrote: > Jan Kiszka wrote: >> [EMAIL PROTECTED] wrote: >> >>> ... >>> Commit from rpm (2006-04-26 17:41 CEST) >>> --------------- >>> >>> Make IPIPE_TRACE_PATHS configurable >>> >>> ipipe v2.6/common/kernel/ipipe/tracer.c 1.10 >>> ipipe v2.6/common/kernel/ipipe/Kconfig.trace 1.4 >> >> >> From a quick glance it appears to me you provided a nice interface to >> break some stuff :). At least the explanation is not correct. >> >> Those four paths are required to 1) always have an active path at hand >> for recording, 2+3) keep the latest max or frozen path, and 4) escape >> with to an alternative slot during max/frozen updates in case the >> previous one is currently locked for output or whatever and cannot >> become the new active path. >> >> So, the absolute minimum is 3 when there is definitely no concurrent >> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that >> users may want to define their own begin/end points if >> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical >> use so far. >> >> What is your idea behind it? >> > > My idea is that 4 paths consume way too much memory and causes my > embedded ppc setup to choke at boot. The usual culprits like a bad > download address passed to u-boot and friends are not involved this > time, so until I figure out what on earth is causing this havoc, I'd > like to be able to lower this value to 2 by configuration. >
Then better make IPIPE_TRACE_POINTS configurable. Also the whole ipipe_trace_begin/end interface could be made optional so that the number of paths could be reduced by _1_ (not more...). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
