lkml.org 
[lkml]   [2003]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.036 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site