[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    [PATCH v2] Dynamic tick support
From:       Tsuyoshi Ozawa <ozawa+bsd () t-oza ! net>
Date:       2010-04-27 15:02:25
Message-ID: s2i411a180c1004270802g37a24d87j903723c09e1fc713 () mail ! gmail ! com
[Download RAW message or body]

Hello,

I'd like you to review dynticks v2 patch for FreeBSD 8.0.
http://gist.github.com/380820

This v2 patch to add dynamic tick support can switch its tick mode
automatically.

Switch from pertick mode to dyntick mode before cpu_idle() is called
in sched_idled. Doing this reduces needless tick. After being called
cpu_idle(), switch its mode vice versa.

By taking on this algorithm, I think I can eliminate the need for
modifiying callout queue operation - callout_reset() and callout_delete().
When CPU is idle, callout queue ops may not be called, because no process
is on the CPU. As the result, no ciritical section is born. Is this OK?
If I'm wrong, please point out:)

I did the benchmark that I posted my blog against this new kernel.
( http://tsuyoshiozawa.blogspot.com/2010/03/started-to-implement-dynticks-in.html
)

If CPU is active(=in pertick mode), VMM process consumes about 35%.
Meanwhile if CPU is idle(in dyntick mode), VMM process consumes only
10% on my environment. Of course, its mode switching is done automatically.
It seems work well :D

As a next step, I'll implement HPET timer to work correctly in the case
that CPU is sleeping deeply (e.g. CPU is sleeping deeply to the point of
local apic timer's stopping).

However, it cause a lot of code duplication to add dynamic tick support
for each timer device driver layer.

I think it's time to divorse timer device driver from callout queue.
To accomplish this, I propose vtimer - timer operation abstraction
layer. Its name is from vfs. By defining some callback APIs such as
vtimer->oneshot(), vtimer->periodic() or something, it's possible
to avoid code dupulication and tight coupling around some switching code
(e.g switch_to_dyntick() and switch_to_periodic()).

But I know that it must be very big change to modify all timer device
driver's code.  I think hybrid architecture - we can select existing drivers
and modified drivers to support dynticks - is down to earth.

This is only my opinion, so let's discuss :D
Thank you!

Very truly yours
OZAWA Tsuyoshi
<ozawa@t-oza.net>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]