WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Scheduler guts question

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Scheduler guts question
From: Andrew Biggadike <biggadike@xxxxxxx>
Date: Fri, 4 Mar 2005 21:20:35 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 05 Mar 2005 02:22:04 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD52A277C@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <516F50407E01324991DD6D07B0531AD52A277C@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
Magenheimer, Dan (HP Labs Fort Collins) <dan.magenheimer@xxxxxx> wrote:
> Looking at the code, I am missing some key connection
> between the interrupt routines and the scheduler routines.
> Perhaps there is some hidden call in a macro or in
> a function pointer indirection that I am missing.
>
> Could someone walk me through at a low level the sequence
> of Xen/x86 calls that occur when a timer interrupt results in
> some timer expiration that results in the currently running
> domain getting "paused" and another domain launched?

There are certainly better people to address this, since I just started
looking at this code last week, but here's what I've figured out so far.

start_of_day() calls scheduler_init(), in which an ac_timer named
s_timer is initialized for each CPU's schedule_data.  Each time one of
these goes off the s_timer_fn() function is invoked which raises the
SCHEDULER_SOFTIRQ.  Later, setup() calls schedulers_start(), which
invokes s_timer_fn() for the first time to raise the first scheduler
softirq.

__enter_scheduler(), which is attached to the scheduler softirq by the
call to open_softirq() in scheduler_init(), removes the ac_timer when
starting, then adds a new one based on the time slice provided by the
scheduler's do_schedule() routine.  See the "reprogram the timer"
comment in __enter_scheduler().  When that timer goes off the scheduler
softirq will be raised by s_timer_fn() again, causing
__enter_scheduler() to be invoked again.

The softirqs are handled in entry.S.  ret_from_intr checks whether there
are events pending and, if so, jumps to test_all_events.  (It appears
that several places jump to test_all_events and it naturally follows a
hypercall invocation.)  test_all_events checks for pending softirqs, and
jumps to process_softirqs to handle them.  This calls do_softirq() (in
softirq.c), which indirectly invokes __enter_scheduler() through the
softirq_handlers method table.

The ac_timer functions (s_timer_fn for the scheduler timer) are invoked
by ac_timer_softirq_action() which is invoked (also by do_softirq())
when AC_TIMER_SOFTIRQ is raised.  This ac_timer softirq is raised by
smp_apic_timer_interrupt() (and timer_interrupt() if there is no apic).
Note that smp_apic_timer_interrupt() is invoked by the
apic_timer_interrupt() function created by the
BUILD_SMP_TIMER_INTERRUPT() macro in irq.h (the use of the macro is in
i8259.c) and registered in the timer's interrupt gate in init_IRQ()
(which is also called by start_of_day()).


So, a timer interrupt gives:
o timer interrupt ->
   apic_timer_interrupt() ->
    smp_apic_timer_interrupt() -> raises AC_TIMER_SOFTIRQ

Then, next time leaving Xen (through entry.S):
o test_all_events: ->
   process_softirqs: ->
    do_softirq() ->
     softirq_handlers[AC_TIMER_SOFTIRQ] == ac_timer_softirq_action() ->
      s_timer_fn() -> raises SCHEDULER_SOFTIRQ 

Then, since AC_TIMER_SOFTIRQ == SCHEDULER_SOFTIRQ - 1, the next
iteration of do_softirq()'s loop invokes the scheduler:
o do_softirq() ->
   softirq_handlers[SCHEDULER_SOFTIRQ] == __enter_scheduler()


Note that I'm looking at 2.0.4.  Also, there's a good chance that some
of this is not quite right or complete, in which case I'd appreciate
being corrected by someone who has a better understanding of the code
base.

Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>