Messages in this thread | | | Date | Thu, 23 Jan 2003 11:55:50 -0800 (PST) | From | "Randy.Dunlap" <> | Subject | Re: alternate high-res-timers patch comments (II) |
| |
On Thu, 23 Jan 2003, Jim Houston wrote:
| > Here are more comments/questions on Jim's alternate high-res-timers | > patch. Some of this is just to understand the code. | > | > a. Why return here and skip profiling? | > Is this an intermediate (high-res) timer interrupt that shouldn't be | > used for profiling? | > | > inline void smp_local_timer_interrupt(struct pt_regs * regs) | > { | > int cpu = smp_processor_id(); | > + | > + if (!run_posix_timers((void *)regs)) | > + return; | > | > x86_do_profile(regs); | > | > b. In kernel/id2ptr.c, | > | > <id_free_cnt>: change cnt to count; just a style thing. | > Linux doesn't use many abbreviations, which makes it easier on | > everyone not having to remember "what is the abbreviation that code | > uses for <whatever>?". | > | > sub_alloc() is recursive. How bounded is it? 32 calls max? | > I'm not totally against recursion, but it needs to be *well-bounded*. | > | > Same for sub_remove(). | > | | Hi Randy, | | Yes, the code fragment in a) above is how the timer code shares the | APIC timer interrupt. There is an in-kernel "Posix style" timer | which is used to generate the profile tick. This still needs | a bit of work to allow the profile tick rate to be set. It defaults | to HZ. In the long run, it might make sense to call the profiling | code from the "case TICK" in check_expiry() perhaps generalizing the interface | so that it would call through a function pointer. There are a few | bits of code that would benifit from having in-kernel repeating timers. | An example would be the code which syncs the hardware clock every 18 minutes. | | Yes, the id allocator uses a recursive approach. This has been discussed | before. It is well bounded, has a tiny stack frame and will never | require more than 6 levels of nesting. I have been following the changes | George has made to his version. This "simple problem" is a real time sink.
Ah, I think I recall akpm commenting on that. Yes, I noticed it is a small stack requirement, and being so bounded doesn't seem like a problem to me.
Thanks, -- ~Randy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |