[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080811080545.d8f42601.randy.dunlap@oracle.com>
Date: Mon, 11 Aug 2008 08:05:45 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Dario Faggioli <raistlin@...ux.it>
Cc: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...l.org>,
Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC 1/1][PATCH] POSIX SCHED_SPORADIC implementation for tasks
and groups
On Mon, 11 Aug 2008 16:45:06 +0200 Dario Faggioli wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index b678803..97fbdfc 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -323,6 +323,44 @@ config CPUSETS
> config HAVE_UNSTABLE_SCHED_CLOCK
> bool
>
> +config POSIX_SCHED_SPORADIC
> + bool "SCHED_SPORADIC POSIX scheduling policy support"
> + default n
> + help
> + Enable the SCHED_SPORADIC POSIX scheduling policy, which mimics
> + the behaviour of the Sporadic Server, a well known mechanism
> + to schedule aperiodic or sporadic tasks in periodic-based fixed
> + priorit real-time systems.
priority
> +
> + To get details about the SCHED_SPORADIC scheduling policy refer to
> + "The Open Group Base Specifications Issue 6", IEEE Std 1003.1,
> + 2004 Edition.
> +
> + [http://www.opengroup.org/onlinepubs/009695399/nfindex.html]
> +
> +config SCHED_SPORADIC_REPL_MAX
> + int "Maximum number of pending recharges"
> + range 1 1000
> + depends on POSIX_SCHED_SPORADIC
> + default 10
> + help
> + Let you chose the maximum number of recharges that can be
Lets you choose
> + pending at a given time instant for a SCHED_SPORADIC task
> + (or task group if group scheduling is configured).
> +
> + The kernel data structure handling the SCHED_SPORADIC scheduling
> + policy for tasks and groups contains a buffer of pending
> + replenishment this size large.
> + For tasks it is dynamically allocated when SCHED_SPORADIC is set
> + as the scheduling policy of the task, while for group it is created
> + as soon as the group itself is allocated.
> +
> + Anyway, since this is going to cause some memory overhead, it is
> + wise to not set this to a too much high value.
wise not to set this to a very high value. // or some other rewording
> + The best value depends on the characteristics of the application
> + you are going to use, but probably a value from 10 to 20 is
> + suitable for the most of the situations.
> +
> config GROUP_SCHED
> bool "Group CPU scheduler"
> depends on EXPERIMENTAL
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists