Re: Non Preemptive Kernel.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 25, 2004 at 20:28:47 +0530, mohanlal jangir wrote:
> Function do_timer is called during timer interrupt (from do_timer_interrupt,
> from timer_interrupt). This increments jiffies and calls
> update_process_times. Function update_process_times checks for pid of
> current process. I believe, if timer_interrupt is called from kernel,
> current->pid will be zero, otherwise non-zero. If current->pid is zero,

No. Syscalls run with current of the process that called them.
Interrupts run with current of whatever process they happen to
interrupt, be it from kernel or userland. Pid 0 is the idle thread.

> current->need_resched is not set. Have a look at following code from
> arch/i386/kernel/time.c
> 
> void do_timer(struct pt_regs *regs)
> {
>  (*(unsigned long *)&jiffies)++;
> #ifndef CONFIG_SMP
>  /* SMP process accounting uses the local APIC timer */
> 
>  update_process_times(user_mode(regs));
> #endif
>  mark_bh(TIMER_BH);
>  if (TQ_ACTIVE(tq_timer))
>   mark_bh(TQUEUE_BH);
> }
> 
> /*
>  * Called from the timer interrupt handler to charge one tick to the current
>  * process.  user_tick is 1 if the tick is user time, 0 for system.
>  */
> void update_process_times(int user_tick)
> {
>  struct task_struct *p = current;
>  int cpu = smp_processor_id(), system = user_tick ^ 1;
> 
>  update_one_process(p, user_tick, system, cpu);
>  if (p->pid) {
>   if (--p->counter <= 0) {
>    p->counter = 0;
>    p->need_resched = 1;
>   }
>   if (p->nice > 0)
>    kstat.per_cpu_nice[cpu] += user_tick;
>   else
>    kstat.per_cpu_user[cpu] += user_tick;
>   kstat.per_cpu_system[cpu] += system;
>  } else if (local_bh_count(cpu) || local_irq_count(cpu) > 1)
>   kstat.per_cpu_system[cpu] += system;
> }
> 
> Regards
> Mohanlal
> 
> ----- Original Message -----
> From: "Dhiman, Gaurav" <Gaurav.Dhiman@ca.com>
> To: "Jan Hudec" <bulb@ucw.cz>; <sajay@temenos.com>
> Cc: <kernelnewbies@nl.linux.org>
> Sent: Friday, June 25, 2004 5:20 PM
> Subject: RE: Non Preemptive Kernel.
> 
> 
> 
> Can you tell us, how the retuirn code of interrupt identifies if the
> control is returning to kernel space or user space. I mean how it comes
> to know that interrupt occurred in kernel space or user space. What
> exactly the returning code on any interrupt checks for this.
> 
> Regards,
> Gaurav
> 
> 
> -----Original Message-----
> From: kernelnewbies-bounce@nl.linux.org
> [mailto:kernelnewbies-bounce@nl.linux.org] On Behalf Of Jan Hudec
> Sent: Friday, June 25, 2004 1:24 PM
> To: sajay@temenos.com
> Cc: kernelnewbies@nl.linux.org
> Subject: Re: Non Preemptive Kernel.
> 
> On Fri, Jun 25, 2004 at 10:56:31 +0530, sajay@temenos.com wrote:
> > Hi,
> >
> > I have a doubt in the Non Preemptive Kernel. In the case of a Non
> > Preemptive Kernel, the Kernel Control Path cannot be preempted unless
> it
> > relinquishes the CPU Voluntarily. In this scenario, supposing a Timer
> > interrupt occurs, how does the timer Interrupt handler find out that a
> 
> > Kernel Control Path is running and hence the process shouldn't be
> > preempted. Or is this handled by the schedule() function.
> 
> It does not. IIRC schedule happens during return to userspace. Return to
> userspace does not happen if the interrupt interrupted kernel code. And
> note, that it really happens during EACH return to userspace (if
> need_resched is set), so if interrupt causes process to wake up, it's
> scheduled soon.
> 
> ------------------------------------------------------------------------
> -------
> Jan 'Bulb' Hudec
> <bulb@ucw.cz>
> 
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive:       http://mail.nl.linux.org/kernelnewbies/
> FAQ:           http://kernelnewbies.org/faq/
> 
> 
> 
-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux