All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>
Cc: root@chaos.analogic.com, "Brown, Len" <len.brown@intel.com>,
	Tim Schmielau <tim@physik3.uni-rostock.de>,
	john stultz <johnstul@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: gradual timeofday overhaul
Date: Thu, 21 Oct 2004 14:17:37 -0700	[thread overview]
Message-ID: <41782771.3060404@mvista.com> (raw)
In-Reply-To: <F989B1573A3A644BAB3920FBECA4D25A011F96CB@orsmsx407>

Perez-Gonzalez, Inaky wrote:
>>From: Richard B. Johnson
>>
>>You need that hardware interrupt for more than time-keeping.
>>Without a hardware-interrupt, to force a new time-slice,
>>
>> 	for(;;)
>>            ;
>>
>>... would allow a user to grab the CPU forever ...
> 
> 
> But you can also schedule, before switching to the new task, 
> a local interrupt on the running processor to mark the end 
> of the timeslice. When you enter the scheduler, you just need 
> to remove that; devil is in the details, but it should be possible
> to do in a way that doesn't take too much overhead.

Well, that is part of the accounting overhead the increases with context switch 
rate.  You also need to include the time it takes to figure out which of the 
time limits is closes (run time limit, profile time, slice time, etc).  Then, 
you also need to remove the timer when switching away.  No, it is not a lot, but 
it is way more than the nothing we do when we can turn it all over to the 
periodic tick.  The choice is load sensitive overhead vs flat overhead.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/


  reply	other threads:[~2004-10-21 21:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-21  8:32 gradual timeofday overhaul Perez-Gonzalez, Inaky
2004-10-21 21:17 ` George Anzinger [this message]
2004-10-21 22:40   ` Chris Friesen
2004-10-25 23:12     ` George Anzinger
2004-10-25 23:51       ` Chris Friesen
  -- strict thread matches above, loose matches on Subject: below --
2004-10-22  0:29 Perez-Gonzalez, Inaky
2004-10-21 21:32 Perez-Gonzalez, Inaky
2004-10-21 22:36 ` Chris Friesen
2004-10-22  0:21 ` George Anzinger
2004-10-19 18:21 process start time set wrongly at boot for kernel 2.6.9 Jerome Borsboom
2004-10-19 20:11 ` john stultz
2004-10-20  0:42   ` Tim Schmielau
2004-10-20  0:59     ` john stultz
2004-10-20  3:05       ` gradual timeofday overhaul Tim Schmielau
2004-10-20  7:47         ` Len Brown
2004-10-20 15:09           ` George Anzinger
2004-10-20 15:59             ` Richard B. Johnson
2004-10-20 15:17           ` George Anzinger
2004-10-20 17:09           ` Lee Revell
2004-10-20 21:42             ` Len Brown
2004-10-20 18:13         ` john stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41782771.3060404@mvista.com \
    --to=george@mvista.com \
    --cc=inaky.perez-gonzalez@intel.com \
    --cc=johnstul@us.ibm.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=tim@physik3.uni-rostock.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.