Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01

From: George Anzinger (george_at_mvista.com)
Date: 08/03/05

  • Next message: Martin J. Bligh: "Re: 2.6.13-rc3-mm3" 
    Date:	Tue, 02 Aug 2005 18:12:27 -0700
To: Steven Rostedt <rostedt@goodmis.org>

    Steven Rostedt wrote:
    > On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
    >
    >>Couldn't you just do some math off current->timestamp to see how long
    >>the task has been running? This per arch stuff seems a bit invasive..
    >
    >
    > The thing is, I'm tracking how long the task is running in the kernel
    > without doing a schedule. That's actually easy, but I don't want to
    > count when the task is in userspace. The per-arch is only updating so
    > that we don't count user space, otherwise the count could be in the
    > task_struct. If there is an arch-independent way to tell if a task is
    > running in user-space or kernel when an interrupt goes off then I would
    > use it. The per arch is actually easy, and I would write it, but I
    > don't have the hardware now to test it. I could at least do PPC and
    > MIPS since I'm quite familiar with both, but I don't currently have a
    > cross compiler to compile it.
    >
    > I understand your point, I would really prefer an arch independent
    > solution, but the timestamp from current just wont cut it. Have another
    > idea, I'm all open for it.

    How about something like:
            if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs)) > MAGIC)

    The idea is that an interrupt from user space will be the ONLY thing on
    the stack while an interrupt from the kernel will have kernel stack
    under it. Current is the bottom end of the kernel stack and regs +
    sizeof(pt_regs) is where the interrupt context started. Assumptions a)
    stack grows down, b) no switch stack at interrupt.
    MAGIC is some small number. For x86 user it is actually zero, don't
    know about others but the saved context should be the first thing on the
    stack so a minimun frame size should do. 

    -- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/
  • Next message: Martin J. Bligh: "Re: 2.6.13-rc3-mm3"

    Relevant Pages

    • Re: Interrupt context...
      ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
      (comp.os.linux.development.system)
    • Re: VxWorks Interrupts
      ... Where could find the memory map when VxWorks is running or booting... ... That's where the ISR_STACK_SIZE is set for the kernel. ... Some of this gets changed for cpu's that don't have interrupt stacks, ... and gets permuted for cpu's where the stack grows upwards toward higher ...
      (comp.os.vxworks)
    • x86_64 kernel stack organization
      ... I could not find a document that described the x86_64 kernel stack ... Interrupt stack. ... Used for external hardware interrupts. ...
      (Linux-Kernel)
    • Re: Sudden reboot
      ... kernel that will will immediately suspend the process, ... The debug utility is used to analyze the crash file. ... time) and display the stack and registers. ... but an unimplemented interrupt or error interrupt could ...
      (comp.unix.solaris)
    • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
      ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
      (Full-Disclosure)