From: Juri Lelli <juri.lelli@arm.com>
To: "Bill Huey (hui)" <bill.huey@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, Dario Faggioli <raistlin@linux.it>,
Alessandro Zummo <a.zummo@towertech.it>,
Thomas Gleixner <tglx@linutronix.de>,
KY Srinivasan <kys@microsoft.com>,
Amir Frenkel <frenkel.amir@gmail.com>,
Bdale Garbee <bdale@gag.com>, luca abeni <luca.abeni@unitn.it>
Subject: Re: [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC
Date: Wed, 13 Apr 2016 09:57:20 +0100 [thread overview]
Message-ID: <20160413085708.GB11651@pablo> (raw)
In-Reply-To: <1460438960-32060-1-git-send-email-bill.huey@gmail.com>
[+Luca, as he might be interested]
Hi,
On 11/04/16 22:29, Bill Huey (hui) wrote:
> Hi,
>
> This a crude cyclic scheduler implementation. It uses SCHED_FIFO tasks
> and runs them according to a map pattern specified by a 64 bit mask. Each
> bit corresponds to an entry into an 64 entry array of
> 'struct task_struct'. This works single core CPU 0 only for now.
>
> Threads are 'admitted' to this map by an extension to the ioctl() via the
> of (rtc) real-time clock interface. The bit pattern then determines when
> the task will run or activate next.
>
> The /dev/rtc interface is choosen for this purpose because of its
> accessibilty to userspace. For example, the mplayer program already use
> it as a timer source and could possibly benefit from being sync to a
> vertical retrace interrupt during decoding. Could be an OpenGL program
> needing precisely scheduler support for those same handling vertical
> retrace interrupts, low latency audio and timely handling of touch
> events amognst other uses.
>
Interesting! I read doc patch and only skimmed through the others, but
I seem to already have a general type of question.
Since you seem familiar with SCHED_DEADLINE [1] (you refer to deadline
scheduling in the doc patch and Dario is in CC :-)), what do you think
is wrong with just use that for this type of workloads?
AFAIK, mplayer (like) type of workloads already play well with deadline
scheduling, and SCHED_DEADLINE is mainline and actively maintained and
developed [2].
Best,
- Juri
[1] http://onlinelibrary.wiley.com/doi/10.1002/spe.2335/abstract
[2] http://events.linuxfoundation.org/sites/events/files/slides/SCHED_DEADLINE-20160404.pdf
> There is also a need for some kind of blocking/yielding interface that can
> return an overrun count for when the thread utilizes more time than
> allocated for that frame. The read() function in rtc is overloaded for this
> purpose and reports overrun events. Yield functionality has yet to be fully
> tested.
>
> I apologize for any informal or misused of terminology as I haven't fully
> reviewed all of the academic literature regarding these kind of schedulers.
> I welcome suggestions and corrects etc
>
> Special thanks to includes...
>
> Peter Ziljstra (Intel), Steve Rostedt (Red Hat), Rik van Riel (Red Hat) for
> encouraging me to continue working in the Linux kernel community and being
> generally positive and supportive.
>
> KY Srinivasan (formerly Novell now Microsoft) for discussion of real-time
> schedulers and pointers to specifics on that topic. It was just a single
> discussion but was basically the inspiration for this kind of work.
>
> Amir Frenkel (Palm), Kenneth Albanowski (Palm), Bdale Garbee (HP) for the
> amazing place that was Palm, Kenneth for being a co-conspirator with this
> scheduler. This scheduler was inspired by performance work that I did
> at Palm's kernel group along with discussions with the multimedia team
> before HP kill webOS off. Sad and infuriating moment.
>
> Maybe, in a short while, the community will understand the value of these
> patches for -rt and start solving the general phenomenon of high performance
> multi-media and user interactivity problems more properly with both a
> scheduler like this and -rt shipped as default in the near future.
>
> [Also, I'd love some kind of sponsorship to continue what I think is
> critical work versus heading back into the valley]
>
> ---
>
> Bill Huey (hui) (12):
> Kconfig change
> Reroute rtc update irqs to the cyclic scheduler handler
> Add cyclic support to rtc-dev.c
> Anonymous struct initialization
> Task tracking per file descriptor
> Add anonymous struct to sched_rt_entity
> kernel/userspace additions for addition ioctl() support for rtc
> Compilation support
> Add priority support for the cyclic scheduler
> Export SCHED_FIFO/RT requeuing functions
> Cyclic scheduler support
> Cyclic/rtc documentation
>
> Documentation/scheduler/sched-cyclic-rtc.txt | 468 ++++++++++++++++++++
> drivers/rtc/Kconfig | 5 +
> drivers/rtc/class.c | 3 +
> drivers/rtc/interface.c | 23 +
> drivers/rtc/rtc-dev.c | 161 +++++++
> include/linux/init_task.h | 18 +
> include/linux/rtc.h | 3 +
> include/linux/sched.h | 15 +
> include/uapi/linux/rtc.h | 4 +
> kernel/sched/Makefile | 1 +
> kernel/sched/core.c | 13 +
> kernel/sched/cyclic.c | 620 +++++++++++++++++++++++++++
> kernel/sched/cyclic.h | 86 ++++
> kernel/sched/cyclic_rt.h | 7 +
> kernel/sched/rt.c | 41 ++
> 15 files changed, 1468 insertions(+)
> create mode 100644 Documentation/scheduler/sched-cyclic-rtc.txt
> create mode 100644 kernel/sched/cyclic.c
> create mode 100644 kernel/sched/cyclic.h
> create mode 100644 kernel/sched/cyclic_rt.h
>
> --
> 2.5.0
>
next prev parent reply other threads:[~2016-04-13 8:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 5:29 [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 01/12] Kconfig change Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 02/12] Reroute rtc update irqs to the cyclic scheduler handler Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 03/12] Add cyclic support to rtc-dev.c Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 04/12] Anonymous struct initialization Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 05/12] Task tracking per file descriptor Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 06/12] Add anonymous struct to sched_rt_entity Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 07/12] kernel/userspace additions for addition ioctl() support for rtc Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 08/12] Compilation support Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 09/12] Add priority support for the cyclic scheduler Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 10/12] Export SCHED_FIFO/RT requeuing functions Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 11/12] Cyclic scheduler support Bill Huey (hui)
2016-04-12 5:29 ` [PATCH RFC v0 12/12] Cyclic/rtc documentation Bill Huey (hui)
2016-04-12 5:58 ` [PATCH RFC v0 00/12] Cyclic Scheduler Against RTC Mike Galbraith
[not found] ` <CAAmnkz=X4TtY7LQwPuWWD0q99XeZQT+53RZ_7dNb3P=X=+jxrg@mail.gmail.com>
2016-04-12 6:05 ` Mike Galbraith
2016-04-13 8:57 ` Juri Lelli [this message]
2016-04-13 9:37 ` Bill Huey (hui)
2016-04-13 10:08 ` Juri Lelli
2016-04-13 10:35 ` Bill Huey (hui)
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=20160413085708.GB11651@pablo \
--to=juri.lelli@arm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=a.zummo@towertech.it \
--cc=bdale@gag.com \
--cc=bill.huey@gmail.com \
--cc=frenkel.amir@gmail.com \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@unitn.it \
--cc=raistlin@linux.it \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).