All of lore.kernel.org
 help / color / mirror / Atom feed
* Tickles scheduler
@ 2010-10-26  7:52 Dragoslav Zaric
  2010-10-26  8:05 ` Martin Nybo Andersen
  0 siblings, 1 reply; 7+ messages in thread
From: Dragoslav Zaric @ 2010-10-26  7:52 UTC (permalink / raw)
  To: linux-kernel

Did anybody test and compare work of ticking and tickles scheduler ?

Currently I think it is implemented as ticking scheduler with
hard-coded frequency (usually 100 Hz).

Personally I think that tickles scheduler is much better solution, but
maybe I am over-view something and
maybe there are side effects when implementation starts ? Instead of
tick, we can wait for events to happen
(for example IRQ, add or remove process from list), and when periodic
actions are needed, we can time
schedule them dynamically based on system load.

Can somebody give me some insight in this issue if he has any
experience with this ?

Is it at all possible to implement kernel without ticking, spin system
by events and periods ?
Maybe ticking is still best solution to have fast responding system ?

Kind regards

-- 
Dragoslav Zaric

Professional Programmer
MSc Astrophysics

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-26  7:52 Tickles scheduler Dragoslav Zaric
@ 2010-10-26  8:05 ` Martin Nybo Andersen
  2010-10-27 22:26   ` Christoph Lameter
  0 siblings, 1 reply; 7+ messages in thread
From: Martin Nybo Andersen @ 2010-10-26  8:05 UTC (permalink / raw)
  To: Dragoslav Zaric; +Cc: linux-kernel

On Tue, 26 Oct 2010, Dragoslav Zaric wrote:

> [...]
>
> Is it at all possible to implement kernel without ticking, spin system
> by events and periods ?

You can compile with CONFIG_NO_HZ=n if you want a ticking kernel.

> Maybe ticking is still best solution to have fast responding system ?

My guesses are that it has already been benchmarked for speed, but you can 
still test it yourself.
At least power usage/battery times is much better with a tickless kernel.

> Kind regards
>
> -- 
> Dragoslav Zaric

-- 
Regards,
Martin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-26  8:05 ` Martin Nybo Andersen
@ 2010-10-27 22:26   ` Christoph Lameter
  2010-10-28 10:19     ` Dragoslav Zaric
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Lameter @ 2010-10-27 22:26 UTC (permalink / raw)
  To: Martin Nybo Andersen; +Cc: Dragoslav Zaric, linux-kernel

On Tue, 26 Oct 2010, Martin Nybo Andersen wrote:

> On Tue, 26 Oct 2010, Dragoslav Zaric wrote:
>
> > [...]
> >
> > Is it at all possible to implement kernel without ticking, spin system
> > by events and periods ?
>
> You can compile with CONFIG_NO_HZ=n if you want a ticking kernel.

The kernel always ticks when a process is running CONFIG_NO_HZ does
nothing for that.

> > Maybe ticking is still best solution to have fast responding system ?

I think we need a tickless kernel.... Yes....

> My guesses are that it has already been benchmarked for speed, but you can
> still test it yourself.
> At least power usage/battery times is much better with a tickless kernel.

Well yes CONFIG_NO_HZ really should say CONFIG_NO_HZ_IDLE. You have
no ticks when a cpu is idle. Otherwise we are ticking...


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-27 22:26   ` Christoph Lameter
@ 2010-10-28 10:19     ` Dragoslav Zaric
  2010-10-28 13:47       ` Christoph Lameter
  0 siblings, 1 reply; 7+ messages in thread
From: Dragoslav Zaric @ 2010-10-28 10:19 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-kernel

1.Currently processes in the system are in some kind of list I think
(double circular).
So what if we assign each process structure (task_struct) property for
priority (maybe already there)
and another property which is time how long should run. So instead
having ticker in system,
each process runs itself predetermined period of time based on
priority and probably few more
parameters that should be in algorithm.

2. Second, when adding process into list, we can have separate side
lists, created in advance (something
like slab), where each lists hold tasks of same priority. So when we
add new process to list, at same
time we add it to his priority list. Than scheduler goes trough these
lists, based on priority and each
tasks hold it's running time. So we have two points to ease algorithm,
lists with single priority and time inside
each process task_struct related to priority.

3. In this way time-granularity of the system is high and allows for
real-time behavior, because we do
not have outside time that we "cut" in the middle when interrupt
happens, we just interrupt current process and when
finished, scheduler continue to walk trough lists of processes that
run its own time.

regards

On Thu, Oct 28, 2010 at 2:26 AM, Christoph Lameter <cl@linux.com> wrote:
> On Tue, 26 Oct 2010, Martin Nybo Andersen wrote:
>
>> On Tue, 26 Oct 2010, Dragoslav Zaric wrote:
>>
>> > [...]
>> >
>> > Is it at all possible to implement kernel without ticking, spin system
>> > by events and periods ?
>>
>> You can compile with CONFIG_NO_HZ=n if you want a ticking kernel.
>
> The kernel always ticks when a process is running CONFIG_NO_HZ does
> nothing for that.
>
>> > Maybe ticking is still best solution to have fast responding system ?
>
> I think we need a tickless kernel.... Yes....
>
>> My guesses are that it has already been benchmarked for speed, but you can
>> still test it yourself.
>> At least power usage/battery times is much better with a tickless kernel.
>
> Well yes CONFIG_NO_HZ really should say CONFIG_NO_HZ_IDLE. You have
> no ticks when a cpu is idle. Otherwise we are ticking...
>
>



-- 
Dragoslav Zaric

Professional Programmer
MSc Astrophysics

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-28 10:19     ` Dragoslav Zaric
@ 2010-10-28 13:47       ` Christoph Lameter
  2010-10-28 17:28         ` Mark Hounschell
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Lameter @ 2010-10-28 13:47 UTC (permalink / raw)
  To: Dragoslav Zaric; +Cc: linux-kernel

The current plan is to switch off the tick when a process is running that
cannot be preempted ("realtime" (very bad choice of terms) tasks).


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-28 13:47       ` Christoph Lameter
@ 2010-10-28 17:28         ` Mark Hounschell
  2010-10-28 18:18           ` Christoph Lameter
  0 siblings, 1 reply; 7+ messages in thread
From: Mark Hounschell @ 2010-10-28 17:28 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: Dragoslav Zaric, linux-kernel

On 10/28/2010 09:47 AM, Christoph Lameter wrote:
> The current plan is to switch off the tick when a process is running that
> cannot be preempted ("realtime" (very bad choice of terms) tasks).
> 

In what kind of time frame is this plan? And in the plan what will be the criteria for
"cannot be preempted"?

Thanks
Mark

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Tickles scheduler
  2010-10-28 17:28         ` Mark Hounschell
@ 2010-10-28 18:18           ` Christoph Lameter
  0 siblings, 0 replies; 7+ messages in thread
From: Christoph Lameter @ 2010-10-28 18:18 UTC (permalink / raw)
  To: Mark Hounschell; +Cc: Dragoslav Zaric, linux-kernel

On Thu, 28 Oct 2010, Mark Hounschell wrote:

> On 10/28/2010 09:47 AM, Christoph Lameter wrote:
> > The current plan is to switch off the tick when a process is running that
> > cannot be preempted ("realtime" (very bad choice of terms) tasks).
> >
>
> In what kind of time frame is this plan? And in the plan what will be the criteria for
> "cannot be preempted"?

Time frame is dependent on my available time unless someone else steps
forward to help out. The criteria for "cannot be preempted" could be
initially a process running with SCHED_FIFO.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-10-28 18:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-26  7:52 Tickles scheduler Dragoslav Zaric
2010-10-26  8:05 ` Martin Nybo Andersen
2010-10-27 22:26   ` Christoph Lameter
2010-10-28 10:19     ` Dragoslav Zaric
2010-10-28 13:47       ` Christoph Lameter
2010-10-28 17:28         ` Mark Hounschell
2010-10-28 18:18           ` Christoph Lameter

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.