OpenVZ Forum - RDF feed
type: channel
items: [RFC][PATCH 0/6] Add group fairness to CFS - v1
items: [RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq
items: [RFC][PATCH 2/6] task's cpu information needs to be always correct
items: [RFC][PATCH 3/6] core changes in CFS
items: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
items: [RFC][PATCH 5/6] core changes for group fairness
items: [RFC][PATCH 6/6] Hook up to container infrastructure
items: Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
items: Re: [ckrm-tech] [RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq
items: Re: [ckrm-tech] [RFC][PATCH 2/6] task's cpu information needs to be always correct
items: Re: [RFC][PATCH 3/6] core changes in CFS
items: Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
items: Re: [RFC][PATCH 5/6] core changes for group fairness

[RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: Ingo, Here's an update of the group fairness patch I have been working on. Its against CFS v16 (sched-cfs-v2.6.22-rc4-mm2-v16.patch). The core idea is to reuse much of CFS logic to apply fairness at higher hierarchical levels (user, container etc). In this regard CFS engine has been modified to deal with generic 'schedulable entities'. The patches introduce two essential structures in CFS core: - struct sched_entity - represents a schedulable entity in a hierarchy. Task is the lowest element in this hierarchy. Its ancestors could be user, container etc. This structure stores essential attributes/execution-history (wait_runtime etc) which is required by CFS engine to provide fairness between 'struct sched_entities' at the same hierarchy. - struct lrq - represents (per-cpu) runqueue in which ready-to-run 'struct sched_entities' are queued. The fair clock calculation is split to be per 'struct lrq'. Here's a brief description of the patches to follow: Patches 1-3 introduce the essential changes in CFS core to support this concept. They rework existing code w/o any (intended!) change in functionality. Patch 4 fixes some bad interaction between SCHED_RT and SCHED_NORMAL tasks in current CFS. Patch 5 introduces basic changes in CFS core to support group fairness. Patch 6 hooks up scheduler with container patches in mm (as an interface for task-grouping functionality). Changes since last version: - Prelimnary SMP support included (based on the idea outlined at http://lkml.org/lkml/2007/5/25/146) - Task grouping to which fairness is applied is based on Paul Menage's container patches included in -mm tree. Usage of this feature is described in Patch 6/6 - Fix some real time and SCHED_NORMAL interactions (maintain separate nr_running/raw_weighted counters for SCHED_NORMAL tasks) - Support arbitrary levels of hierarchy. Previous version supported only 2 levels. Current version makes no assumption on the number of levels supported. TODO: - Weighted fair-share support Currently …
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:47:24-00:00

[RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq
type: item
description: This patch introduces two new structures: struct sched_entity stores essential attributes/execution-history used by CFS core to drive fairness between 'schedulable entities' (tasks, users etc) struct lrq runqueue used to hold ready-to-run entities These new structures are formed by grouping together existing fields in existing structures (task_struct and rq) and hence represents rework with zero functionality change. Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- fs/proc/array.c | 4 include/linux/sched.h | 43 +++++---- kernel/exit.c | 2 kernel/posix-cpu-timers.c | 16 +-- kernel/sched.c | 186 +++++++++++++++++++++------------------- kernel/sched_debug.c | 86 +++++++++--------- kernel/sched_fair.c | 211 +++++++++++++++++++++++----------------------- kernel/sched_rt.c | 14 +-- 8 files changed, 289 insertions(+), 273 deletions(-) Index: current/include/linux/sched.h =================================================================== --- current.orig/include/linux/sched.h 2007-06-09 15:01:39.000000000 +0530 +++ current/include/linux/sched.h 2007-06-09 15:04:54.000000000 +0530 @@ -872,6 +872,29 @@ void (*task_new) (struct rq *rq, struct task_struct *p); }; +/* CFS stats for a schedulable entity (task, task-group etc) */ +struct sched_entity { + int load_weight; /* for niceness load balancing purposes */ + int on_rq; + struct rb_node run_node; + u64 wait_start_fair; + u64 wait_start; + u64 exec_start; + u64 sleep_start, sleep_start_fair; + u64 block_start; + u64 sleep_max; + u64 block_max; + u64 exec_max; + u64 wait_max; + u64 last_ran; + + s64 wait_runtime; + u64 sum_exec_runtime; + s64 fair_key; + s64 sum_wait_runtime, sum_sleep_runtime; + unsigned long wait_runtime_overruns, wait_runtime_underruns; +}; + struct task_struct { volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */ void *stack; @@ -886,33 +909,15 @@ int oncpu; #endif #endif - int load_weight; /* for niceness load balancing purposes */ int prio, static_prio, normal_prio; - int o…
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:50:46-00:00

[RFC][PATCH 2/6] task's cpu information needs to be always correct
type: item
description: We rely very much on task_cpu(p) to be correct at all times, so that we can correctly find the runqueue from which the task has to be removed or added to. There is however one place in the scheduler where this assumption of task_cpu(p) being correct is broken. This patch fixes that piece of code. (Thanks to Balbir Singh for pointing this out to me) Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- kernel/sched.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) Index: current/kernel/sched.c =================================================================== --- current.orig/kernel/sched.c 2007-06-09 15:07:17.000000000 +0530 +++ current/kernel/sched.c 2007-06-09 15:07:32.000000000 +0530 @@ -4624,7 +4624,7 @@ static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu) { struct rq *rq_dest, *rq_src; - int ret = 0; + int ret = 0, on_rq; if (unlikely(cpu_is_offline(dest_cpu))) return ret; @@ -4640,9 +4640,11 @@ if (!cpu_isset(dest_cpu, p->cpus_allowed)) goto out; - set_task_cpu(p, dest_cpu); - if (p->se.on_rq) { + on_rq = p->se.on_rq; + if (on_rq) deactivate_task(rq_src, p, 0); + set_task_cpu(p, dest_cpu); + if (on_rq) { activate_task(rq_dest, p, 0); check_preempt_curr(rq_dest, p); } -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:52:12-00:00

[RFC][PATCH 3/6] core changes in CFS
type: item
description: This patch introduces core changes in CFS work to operate on generic schedulable entities. The task specific operations (like enqueue, dequeue, task_tick etc) is then rewritten to work off this generic CFS "library". Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- kernel/sched_debug.c | 2 kernel/sched_fair.c | 574 ++++++++++++++++++++++++++++++--------------------- 2 files changed, 345 insertions(+), 231 deletions(-) Index: current/kernel/sched_fair.c =================================================================== --- current.orig/kernel/sched_fair.c 2007-06-09 15:07:16.000000000 +0530 +++ current/kernel/sched_fair.c 2007-06-09 15:07:33.000000000 +0530 @@ -42,19 +42,54 @@ extern struct sched_class fair_sched_class; +/******************************************************************************/ +/* BEGIN : CFS operations on generic schedulable entities */ +/******************************************************************************/ + +static inline struct rq *lrq_rq(struct lrq *lrq) +{ + return container_of(lrq, struct rq, lrq); +} + +static inline struct sched_entity *lrq_curr(struct lrq *lrq) +{ + struct rq *rq = lrq_rq(lrq); + struct sched_entity *se = NULL; + + if (rq->curr->sched_class == &fair_sched_class) + se = &rq->curr->se; + + return se; +} + +static long lrq_nr_running(struct lrq *lrq) +{ + struct rq *rq = lrq_rq(lrq); + + return rq->nr_running; +} + +#define entity_is_task(se) 1 + +static inline struct task_struct *entity_to_task(struct sched_entity *se) +{ + return container_of(se, struct task_struct, se); +} + + /**************************************************************/ /* Scheduling class tree data structure manipulation methods: */ /* - * Enqueue a task into the rb-tree: + * Enqueue a entity into the rb-tree: */ -static inline void __enqueue_task_fair(struct rq *rq, struct task_struct *p) +static inline void __enqueue_entity(struct lrq *lrq, struct sched_entity *p) { - struct rb_node **link = &rq->lrq.tasks_timeline.…
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:53:45-00:00

[RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: Currently nr_running and raw_weighted_load fields in runqueue affect some CFS calculations (like distribute_fair_add, enqueue_sleeper etc). These fields however are shared between tasks of all classes, which can potentialy affect those calculations for SCHED_NORMAL tasks. However I do not know of any bad behaviour caused by not splitting these fields (like this patch does). This split is neverthless needed for subsequent patches. Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- kernel/sched.c | 134 +++++++++++++++++++++++++--------------------------- kernel/sched_fair.c | 65 ++++++++++++++++++++++++- 2 files changed, 128 insertions(+), 71 deletions(-) Index: current/kernel/sched.c =================================================================== --- current.orig/kernel/sched.c 2007-06-09 15:07:32.000000000 +0530 +++ current/kernel/sched.c 2007-06-09 15:07:36.000000000 +0530 @@ -118,6 +118,7 @@ /* CFS-related fields in a runqueue */ struct lrq { + long nr_running; unsigned long raw_weighted_load; #define CPU_LOAD_IDX_MAX 5 unsigned long cpu_load[CPU_LOAD_IDX_MAX]; @@ -125,6 +126,7 @@ u64 fair_clock, delta_fair_clock; u64 exec_clock, delta_exec_clock; + u64 last_tick; /* when did we last smoothen cpu load? */ s64 wait_runtime; unsigned long wait_runtime_overruns, wait_runtime_underruns; @@ -148,12 +150,18 @@ * remote CPUs use both these fields when doing load calculation. */ long nr_running; - struct lrq lrq; + unsigned long raw_weighted_load; +#ifdef CONFIG_SMP + #define CPU_LOAD_IDX_MAX 5 + unsigned long cpu_load[CPU_LOAD_IDX_MAX]; unsigned char idle_at_tick; #ifdef CONFIG_NO_HZ unsigned char in_nohz_recently; #endif +#endif + struct lrq lrq; + u64 nr_switches; /* @@ -589,13 +597,13 @@ static inline void inc_raw_weighted_load(struct rq *rq, const struct task_struct *p) { - rq->lrq.raw_weighted_load += p->se.load_weight; + rq->raw_weighted_load += p->se.load_weight; } static inline void dec_raw_weighted_load(struct rq *rq, const struct task_struct …
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:55:04-00:00

[RFC][PATCH 5/6] core changes for group fairness
type: item
description: This patch introduces the core changes in CFS required to accomplish group fairness at higher levels. It also modifies load balance interface between classes a bit, so that move_tasks (which is centric to load balance) can be reused to balance between runqueues of various types (struct rq in case of SCHED_RT tasks, struct lrq in case of SCHED_NORMAL/BATCH tasks). Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- include/linux/sched.h | 14 ++ kernel/sched.c | 155 ++++++++++++++++-------------- kernel/sched_fair.c | 252 +++++++++++++++++++++++++++++++++++++++++++++----- kernel/sched_rt.c | 49 ++++++++- 4 files changed, 367 insertions(+), 103 deletions(-) Index: current/include/linux/sched.h =================================================================== --- current.orig/include/linux/sched.h 2007-06-09 15:04:54.000000000 +0530 +++ current/include/linux/sched.h 2007-06-09 15:07:37.000000000 +0530 @@ -866,8 +866,13 @@ struct task_struct * (*pick_next_task) (struct rq *rq, u64 now); void (*put_prev_task) (struct rq *rq, struct task_struct *p, u64 now); - struct task_struct * (*load_balance_start) (struct rq *rq); - struct task_struct * (*load_balance_next) (struct rq *rq); +#ifdef CONFIG_SMP + int (*load_balance) (struct rq *this_rq, int this_cpu, + struct rq *busiest, + unsigned long max_nr_move, unsigned long max_load_move, + struct sched_domain *sd, enum idle_type idle, + int *all_pinned, unsigned long *total_load_moved); +#endif void (*task_tick) (struct rq *rq, struct task_struct *p); void (*task_new) (struct rq *rq, struct task_struct *p); }; @@ -893,6 +898,11 @@ s64 fair_key; s64 sum_wait_runtime, sum_sleep_runtime; unsigned long wait_runtime_overruns, wait_runtime_underruns; +#ifdef CONFIG_FAIR_GROUP_SCHED + struct sched_entity *parent; + struct lrq *lrq, /* runqueue on which this entity is (to be) queued */ + *my_q; /* runqueue "owned" by this entity/group */ +#endif }; struct task_struct { Index: current/kernel/sched.c ======================…
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:56:08-00:00

[RFC][PATCH 6/6] Hook up to container infrastructure
type: item
description: This patch hooks up cpu scheduler with Paul Menage's container infrastructure. The container patches allows administrator to create arbitrary groups of tasks and define resource allocation for each group. By registering with container infrastructure, cpu scheduler is made aware of group membership information for each task, creation/deletion of groups etc and can use that information to provide fairness between groups. This mechanism can indirectly be used to provide fairness between users also. All that is needed is a user-space program (which I am working on and will post later) which monitors for PROC_EVENT_UID events (using process event connector) and moves the task to appropriate user-directory in container filesystem. As an example for "HOWTO use this feature", follow these steps: 1. Define CONFIG_FAIR_GROUP_SCHED (General Setup->Fair Group Scheduler) and compile the kernel 2. After booting: # cd /dev # mkdir cpuctl # mount -t container -ocpuctl none /dev/cpuctl # cd cpuctl # mkdir grpA # mkdir grpB # echo some_pid1 > grpA/tasks # echo some_pid2 > grpA/tasks # echo some_pid3 > grpA/tasks # echo some_pid4 > grpA/tasks ... # echo another_pidX > grpB/tasks # echo another_pidY > grpB/tasks All tasks in grpA/tasks should cumulatively share same CPU as all tasks in grpB/tasks. Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> --- include/linux/container_subsys.h | 6 + include/linux/sched.h | 1 init/Kconfig | 8 + kernel/sched.c | 234 ++++++++++++++++++++++++++++++++++++++- kernel/sched_fair.c | 36 ++++-- 5 files changed, 274 insertions(+), 11 deletions(-) Index: current/kernel/sched.c =================================================================== --- current.orig/kernel/sched.c 2007-06-09 15:07:37.000000000 +0530 +++ current/kernel/sched.c 2007-06-09 15:07:38.000000000 +0530 @@ -116,6 +116,39 @@ struct list_head queue[MAX_RT_PRIO]; }; +#ifdef CONFIG_FAIR_GROUP_SCHED + +#include <linux/container.h> + +struct lrq; + +struct task_grp { + struct contain…
creator: Srivatsa Vaddagiri
date: 2007-06-11T15:58:21-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: On Mon, Jun 11, 2007 at 09:17:24PM +0530, Srivatsa Vaddagiri wrote: > TODO: > > - Weighted fair-share support > Currently each group gets "equal" share. Support > weighted fair-share so that some groups deemed important > get more than this "equal" share. I believe it is > possible to use load_weight to achieve this goal > (similar to how niced tasks use it to get differential > bandwidth) [snip] + Fix CFS debug interface to be group aware -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-06-11T16:02:28-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > Ingo, > Here's an update of the group fairness patch I have been > working on. Its against CFS v16 (sched-cfs-v2.6.22-rc4-mm2-v16.patch). thanks! > The core idea is to reuse much of CFS logic to apply fairness at > higher hierarchical levels (user, container etc). In this regard CFS > engine has been modified to deal with generic 'schedulable entities'. > The patches introduce two essential structures in CFS core: > > - struct sched_entity > - represents a schedulable entity in a hierarchy. Task > is the lowest element in this hierarchy. Its ancestors > could be user, container etc. This structure stores > essential attributes/execution-history (wait_runtime etc) > which is required by CFS engine to provide fairness between > 'struct sched_entities' at the same hierarchy. > > - struct lrq > - represents (per-cpu) runqueue in which ready-to-run > 'struct sched_entities' are queued. The fair clock > calculation is split to be per 'struct lrq'. > > Here's a brief description of the patches to follow: > > Patches 1-3 introduce the essential changes in CFS core to support > this concept. They rework existing code w/o any (intended!) change in > functionality. i currently have these 3 patches applied to the CFS queue and it's looking pretty good so far! If it continues to be problem-free i'll release them as part of -v17, just to check that they truly have no bad side-effects (they shouldnt). Then #4 can go into -v18. i've attached my current -v17 tree - it should apply mostly cleanly ontop of the -mm queue (with a minor number of fixups). Could you refactor the remaining 3 patches ontop of this base? There's some rejects in the last 3 patches due to the update_load_fair() change. > Patch 4 fixes some bad interaction between SCHED_RT and SCHED_NORMAL > tasks in current CFS. btw., the plan here is to turn off 'bit 0' in sched_features: i.e. to use the precise statistics to calculate lrq->cpu_load[], not the timer-irq…
creator: Ingo Molnar
date: 2007-06-11T19:37:35-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: * Ingo Molnar <mingo@elte.hu> wrote: > > Patch 4 fixes some bad interaction between SCHED_RT and SCHED_NORMAL > > tasks in current CFS. > > btw., the plan here is to turn off 'bit 0' in sched_features: i.e. to > use the precise statistics to calculate lrq->cpu_load[], not the > timer-irq-sampled imprecise statistics. [...] i mean bit 6, value 64. I flipped around its meaning in -v17-rc4, so the new precise stats code there is now default-enabled - making SMP load-balancing more accurate. Ingo _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Ingo Molnar
date: 2007-06-11T19:39:31-00:00

Re: [ckrm-tech] [RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq
type: item
description: Srivatsa Vaddagiri wrote: > This patch introduces two new structures: > > struct sched_entity > stores essential attributes/execution-history used by CFS core > to drive fairness between 'schedulable entities' (tasks, users etc) > > struct lrq > runqueue used to hold ready-to-run entities > > These new structures are formed by grouping together existing fields in > existing structures (task_struct and rq) and hence represents rework > with zero functionality change. > > Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> [snip] > > +/* CFS-related fields in a runqueue */ > +struct lrq { > + unsigned long raw_weighted_load; > + #define CPU_LOAD_IDX_MAX 5 > + unsigned long cpu_load[CPU_LOAD_IDX_MAX]; > + unsigned long nr_load_updates; > + > + u64 fair_clock, delta_fair_clock; > + u64 exec_clock, delta_exec_clock; > + s64 wait_runtime; > + unsigned long wait_runtime_overruns, wait_runtime_underruns; > + > + struct rb_root tasks_timeline; > + struct rb_node *rb_leftmost; > + struct rb_node *rb_load_balance_curr; > +}; > + Shouldn't the rq->lock move into lrq? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-06-12T02:15:59-00:00

Re: [ckrm-tech] [RFC][PATCH 2/6] task's cpu information needs to be always correct
type: item
description: Srivatsa Vaddagiri wrote: > We rely very much on task_cpu(p) to be correct at all times, so that we > can correctly find the runqueue from which the task has to be removed or > added to. > > There is however one place in the scheduler where this assumption of > task_cpu(p) being correct is broken. This patch fixes that piece of > code. > > (Thanks to Balbir Singh for pointing this out to me) > > Signed-off-by : Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> > Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> > --- > kernel/sched.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) > > Index: current/kernel/sched.c > =================================================================== > --- current.orig/kernel/sched.c 2007-06-09 15:07:17.000000000 +0530 > +++ current/kernel/sched.c 2007-06-09 15:07:32.000000000 +0530 > @@ -4624,7 +4624,7 @@ > static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu) > { > struct rq *rq_dest, *rq_src; > - int ret = 0; > + int ret = 0, on_rq; > > if (unlikely(cpu_is_offline(dest_cpu))) > return ret; > @@ -4640,9 +4640,11 @@ > if (!cpu_isset(dest_cpu, p->cpus_allowed)) > goto out; > > - set_task_cpu(p, dest_cpu); > - if (p->se.on_rq) { > + on_rq = p->se.on_rq; > + if (on_rq) > deactivate_task(rq_src, p, 0); > + set_task_cpu(p, dest_cpu); > + if (on_rq) { > activate_task(rq_dest, p, 0); > check_preempt_curr(rq_dest, p); > } -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-06-12T02:17:08-00:00

Re: [RFC][PATCH 3/6] core changes in CFS
type: item
description: Srivatsa Vaddagiri wrote: > +#define entity_is_task(se) 1 Could you add some comments as to what this means? Should be it boolean instead (true) > /* > - * Enqueue a task into the rb-tree: > + * Enqueue a entity into the rb-tree: Enqueue an entity > -static void limit_wait_runtime(struct rq *rq, struct task_struct *p) > +static void limit_wait_runtime(struct lrq *lrq, struct sched_entity *p) p is a general convention for tasks in the code, could we use something different -- may be "e"? > > static s64 div64_s(s64 divident, unsigned long divisor) > @@ -183,49 +219,51 @@ > * Update the current task's runtime statistics. Skip current tasks that > * are not in our scheduling class. > */ > -static inline void update_curr(struct rq *rq, u64 now) > +static inline void update_curr(struct lrq *lrq, u64 now) > { > - unsigned long load = rq->lrq.raw_weighted_load; > + unsigned long load = lrq->raw_weighted_load; > u64 delta_exec, delta_fair, delta_mine; > - struct task_struct *curr = rq->curr; > + struct sched_entity *curr = lrq_curr(lrq); How about curr_entity? > + struct rq *rq = lrq_rq(lrq); > + struct task_struct *curtask = rq->curr; > > - if (curr->sched_class != &fair_sched_class || curr == rq->idle || !load) > + if (!curr || curtask == rq->idle || !load) Can !curr ever be true? shoudn't we look into the sched_class of the task that the entity belongs to? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-06-12T02:29:22-00:00

Re: [ckrm-tech] [RFC][PATCH 1/6] Introduce struct sched_entity and struct lrq
type: item
description: On Tue, Jun 12, 2007 at 07:45:59AM +0530, Balbir Singh wrote: > > +/* CFS-related fields in a runqueue */ > > +struct lrq { > > + unsigned long raw_weighted_load; > > + #define CPU_LOAD_IDX_MAX 5 > > + unsigned long cpu_load[CPU_LOAD_IDX_MAX]; > > + unsigned long nr_load_updates; > > + > > + u64 fair_clock, delta_fair_clock; > > + u64 exec_clock, delta_exec_clock; > > + s64 wait_runtime; > > + unsigned long wait_runtime_overruns, wait_runtime_underruns; > > + > > + struct rb_root tasks_timeline; > > + struct rb_node *rb_leftmost; > > + struct rb_node *rb_load_balance_curr; > > +}; > > + > > Shouldn't the rq->lock move into lrq? Right now, the per-cpu rq lock protects all (local) runqueues attached with the cpu. At some point, for scalability reasons, we may want to split that to be per-cpu per-local runqueue (as you point out). I will put that in my todo list of things to consider. Thanks for the review! -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-06-12T03:52:45-00:00

Re: [RFC][PATCH 3/6] core changes in CFS
type: item
description: On Tue, Jun 12, 2007 at 07:59:22AM +0530, Balbir Singh wrote: > > +#define entity_is_task(se) 1 > > Could you add some comments as to what this means? sure. Basically this macro tests whether a given schedulable entity is task or not. Other possible schedulable entities could be process, user, container etc. These various entities form a hierarchy with task being at the bottom of the hierarchy. > Should be it boolean instead (true) I don't have a good opinion on this. Would it make sparse friendly? > > + * Enqueue a entity into the rb-tree: > > Enqueue an entity yes > > > -static void limit_wait_runtime(struct rq *rq, struct task_struct *p) > > +static void limit_wait_runtime(struct lrq *lrq, struct sched_entity *p) > > p is a general convention for tasks in the code, could we use something > different -- may be "e"? 'se' perhaps as is used elsewhere. I avoided making that change so that people will see less diff o/p in the patch :) I agree though a better name is needed. > > static s64 div64_s(s64 divident, unsigned long divisor) > > @@ -183,49 +219,51 @@ > > * Update the current task's runtime statistics. Skip current tasks that > > * are not in our scheduling class. > > */ > > -static inline void update_curr(struct rq *rq, u64 now) > > +static inline void update_curr(struct lrq *lrq, u64 now) > > { > > - unsigned long load = rq->lrq.raw_weighted_load; > > + unsigned long load = lrq->raw_weighted_load; > > u64 delta_exec, delta_fair, delta_mine; > > - struct task_struct *curr = rq->curr; > > + struct sched_entity *curr = lrq_curr(lrq); > > How about curr_entity? I prefer its current name, but will consider your suggestion in next iteration. > > + struct rq *rq = lrq_rq(lrq); > > + struct task_struct *curtask = rq->curr; > > > > - if (curr->sched_class != &fair_sched_class || curr == rq->idle || !load) > > + if (!curr || curtask == rq->idle || !load) > > Can !curr ever be true? shoudn't we look into the sched_class of the task > that the entity belongs to? Couple o…
creator: Srivatsa Vaddagiri
date: 2007-06-12T04:22:47-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: On Mon, Jun 11, 2007 at 09:37:35PM +0200, Ingo Molnar wrote: > > Patches 1-3 introduce the essential changes in CFS core to support > > this concept. They rework existing code w/o any (intended!) change in > > functionality. > > i currently have these 3 patches applied to the CFS queue and it's > looking pretty good so far! If it continues to be problem-free i'll > release them as part of -v17, just to check that they truly have no bad > side-effects (they shouldnt). Then #4 can go into -v18. ok. I am also most concerned about not upsetting current performance of CFS when CONFIG_FAIR_GROUP_SCHED is turned off. Staging these patches in incremental versions of CFS is a good idea to test that. > i've attached my current -v17 tree - it should apply mostly cleanly > ontop of the -mm queue (with a minor number of fixups). Could you > refactor the remaining 3 patches ontop of this base? There's some > rejects in the last 3 patches due to the update_load_fair() change. sure, i will rework them on this -v17 snapshot. > > Patch 4 fixes some bad interaction between SCHED_RT and SCHED_NORMAL > > tasks in current CFS. > > btw., the plan here is to turn off 'bit 0' in sched_features: i.e. to > use the precise statistics to calculate lrq->cpu_load[], not the > timer-irq-sampled imprecise statistics. Dmitry has fixed a couple of > bugs in it that made it not work too well in previous CFS versions, but > now we are ready to turn it on for -v17. (indeed in my tree it's already > turned on - i.e. sched_features defaults to '14') On Mon, Jun 11, 2007 at 09:39:31PM +0200, Ingo Molnar wrote: > i mean bit 6, value 64. I flipped around its meaning in -v17-rc4, so the > new precise stats code there is now default-enabled - making SMP > load-balancing more accurate. I must be missing something here. AFAICS, cpu_load calculation still is timer-interrupt driven in the -v17 snapshot you sent me. Besides, there is no change in default value of bit 6 b/n v16 and v17: -unsigned int sysctl_sched_fe…
creator: Srivatsa Vaddagiri
date: 2007-06-12T05:50:24-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: * Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > On Mon, Jun 11, 2007 at 09:39:31PM +0200, Ingo Molnar wrote: > > i mean bit 6, value 64. I flipped around its meaning in -v17-rc4, so the > > new precise stats code there is now default-enabled - making SMP > > load-balancing more accurate. > > I must be missing something here. AFAICS, cpu_load calculation still > is timer-interrupt driven in the -v17 snapshot you sent me. Besides, > there is no change in default value of bit 6 b/n v16 and v17: > > -unsigned int sysctl_sched_features __read_mostly = 1 | 2 | 4 | 8 | 0 | 0; > +unsigned int sysctl_sched_features __read_mostly = 0 | 2 | 4 | 8 | 0 | 0; > > So where's this precise stats based calculation of cpu_load? but there's a change in the interpretation of bit 6: - if (!(sysctl_sched_features & 64)) { - this_load = this_rq->raw_weighted_load; + if (sysctl_sched_features & 64) { + this_load = this_rq->lrq.raw_weighted_load; the update of the cpu_load[] value is timer interrupt driven, but the _value_ that is sampled is not. Previously we used ->raw_weighted_load (at whatever value it happened to be at the moment the timer irq hit the system), now we basically use a load derived from the fair-time passed since the last scheduler tick. (Mathematically it's close to an integral of load done over that period) So it takes all scheduling activities and all load values into account to calculate the average, not just the value that was sampled by the scheduler tick. this, besides being more precise (it for example correctly samples short-lived, timer-interrupt-driven workloads too, which were largely 'invisible' to the previous load calculation method), also enables us to make the scheduler tick hrtimer based in the (near) future. (in essence making the scheduler tick-less even when there are tasks running) > Anyway, do you agree that splitting the cpu_load/nr_running fields so > that: > > rq->nr_running = total count of -all- tasks in runqueue > rq->raw_weighted_load …
creator: Ingo Molnar
date: 2007-06-12T06:26:12-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On 11/06/07, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > Currently nr_running and raw_weighted_load fields in runqueue affect > some CFS calculations (like distribute_fair_add, enqueue_sleeper etc). [ briefly looked.. a few comments so far ] (1) I had an idea of per-sched-class 'load balance' calculator. So that update_load() (as in your patch) would look smth like : ... struct sched_class *class = sched_class_highest; unsigned long total = 0; do { total += class->update_load(..., now); class = class->next; } while (class); ... and e.g. update_load_fair() would become a fair_sched_class :: update_load(). That said, all the sched_classes would report a load created by their entities (tasks) over the last sampling period. Ideally, the calculation should not be merely based on the 'raw_weighted_load' but rather done in a similar way to update_load_fair() as in v17. I'll take a look at how it can be mapped on the current v17 codebase (including your patches #1-3) and come up with some real code so we would have a base for discussion. (2) > static void entity_tick(struct lrq *lrq, struct sched_entity *curr) > { > struct sched_entity *next; > struct rq *rq = lrq_rq(lrq); > u64 now = __rq_clock(rq); > > + /* replay load smoothening for all ticks we lost */ > + while (time_after_eq64(now, lrq->last_tick)) { > + update_load_fair(lrq); > + lrq->last_tick += TICK_NSEC; > + } I think, it won't work properly this way. The first call returns a load for last TICK_NSEC and all the consequent ones report zero load ('this_load = 0' internally).. as a result, we will get a lower load than it likely was. I guess, update_load_fair() (as it's in v17) could be slightly changed to report the load for an interval of time over which the load statistics have been accumulated (delta_exec_time and fair_exec_time): update_load_fair(Irq, now - Irq->last_tick) This new (second) argument would be used instead of TICK_NSEC (internally in update_load_fair()) ... but again, I'll come up wit…
creator: Dmitry Adamushko
date: 2007-06-12T09:03:36-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On Tue, Jun 12, 2007 at 11:03:36AM +0200, Dmitry Adamushko wrote: > I had an idea of per-sched-class 'load balance' calculator. So that > update_load() (as in your patch) would look smth like : > > ... > struct sched_class *class = sched_class_highest; > unsigned long total = 0; > > do { > total += class->update_load(..., now); > class = class->next; > } while (class); > ... > > and e.g. update_load_fair() would become a fair_sched_class :: > update_load(). > > That said, all the sched_classes would report a load created by their > entities (tasks) over the last sampling period. Ideally, the > calculation should not be merely based on the 'raw_weighted_load' but > rather done in a similar way to update_load_fair() as in v17. I like this idea. It neatly segregates load calculation across classes. It effectively replaces what update_load() function I introduced in Patch #4. Btw what will update_load_rt() return? > > static void entity_tick(struct lrq *lrq, struct sched_entity *curr) > > { > > struct sched_entity *next; > > struct rq *rq = lrq_rq(lrq); > > u64 now = __rq_clock(rq); > > > >+ /* replay load smoothening for all ticks we lost */ > >+ while (time_after_eq64(now, lrq->last_tick)) { > >+ update_load_fair(lrq); > >+ lrq->last_tick += TICK_NSEC; > >+ } > > I think, it won't work properly this way. The first call returns a > load for last TICK_NSEC and all the consequent ones report zero load > ('this_load = 0' internally).. mm .. exec_delta64 = this_lrq->delta_exec_clock + 1; this_lrq->delta_exec_clock = 0; So exec_delta64 (and fair_delta64) should be min 1 in successive calls. How can that lead to this_load = 0? The idea behind 'replay lost ticks' is to avoid load smoothening of -every- lrq -every- tick. Lets say that there are ten lrqs (corresponding to ten different users). We load smoothen only the currently active lrq (whose task is currently running). Other lrqs load get smoothened as soon as they become active next time (thus catching up with all lost ti…
creator: Srivatsa Vaddagiri
date: 2007-06-12T10:26:22-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: [ resending ..my earlier reply doesn't seem to have made it to lkml ] On Tue, Jun 12, 2007 at 08:26:12AM +0200, Ingo Molnar wrote: > > So where's this precise stats based calculation of cpu_load? > > but there's a change in the interpretation of bit 6: > > - if (!(sysctl_sched_features & 64)) { > - this_load = this_rq->raw_weighted_load; > + if (sysctl_sched_features & 64) { > + this_load = this_rq->lrq.raw_weighted_load; > > the update of the cpu_load[] value is timer interrupt driven, but the > _value_ that is sampled is not. [...] Ah ..ok. Should have realized it earlier. Thanks for the education, but: > Previously we used ->raw_weighted_load > (at whatever value it happened to be at the moment the timer irq hit the > system), now we basically use a load derived from the fair-time passed > since the last scheduler tick. [...] Isn't that biasing the overall cpu load to be dependent on SCHED_NORMAL task load (afaics update_curr_rt doesn't update fair_clock at all)? What if a CPU had just real-time tasks and no SCHED_NORMAL/BATCH tasks? Would the cpu_load be seen to be very low? [ Dmitry's proposal for a per-class update_load() callback seems to be a good thing in this regard ] > > Just to be clear, by container patches, I am referring to "process" > > container patches from Paul Menage [1]. They aren't necessarily tied > > to "virtualization-related" container support in -mm tree, although I > > believe that "virtualization-related" container patches will make use > > of the same "process-related" container patches for their > > task-grouping requirements. Phew ..we need better names! > > i'd still like to hear back from Kirill & co whether this framework is > flexible enough for their work (OpenVZ, etc.) too. sure .. i would love to hear their feedback as well on the overall approach of these patches, which is: 1. Using Paul Menage's process container patches as the basis of task-grouping functionaility. I think there is enough consensus on this already (more impo…
creator: Srivatsa Vaddagiri
date: 2007-06-12T10:56:37-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On 12/06/07, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > On Tue, Jun 12, 2007 at 11:03:36AM +0200, Dmitry Adamushko wrote: > > I had an idea of per-sched-class 'load balance' calculator. So that > > update_load() (as in your patch) would look smth like : > > > > ... > > struct sched_class *class = sched_class_highest; > > unsigned long total = 0; > > > > do { > > total += class->update_load(..., now); > > class = class->next; > > } while (class); > > ... > > > > and e.g. update_load_fair() would become a fair_sched_class :: > > update_load(). > > > > That said, all the sched_classes would report a load created by their > > entities (tasks) over the last sampling period. Ideally, the > > calculation should not be merely based on the 'raw_weighted_load' but > > rather done in a similar way to update_load_fair() as in v17. > > I like this idea. It neatly segregates load calculation across classes. > It effectively replaces what update_load() function I introduced in > Patch #4. Good. (a minor disclaimer :) We discussed it a bit with Ingo and I don't remember who first expressed this idea in written words (although I seem to remember, I did have it in mind before -- it's not rocket science after all :) > > Btw what will update_load_rt() return? Well, as a _temporary_ stub - just return the 'raw_weighted_load' contributed by the RT tasks.. Ideally, we'd like a similar approach to the update_fair_load() -- i.e. we need the run-time history of rt_sched_class's (like of any other class) tasks over the last sampling period, so e.g. we do account periodic RT tasks which happen to escape accounting through 'raw_weghted_load' due to the fact that they are not active at the moment of timer interrupts (when 'raw_weighted_load' snapshots are taken). > > > > static void entity_tick(struct lrq *lrq, struct sched_entity *curr) > > > { > > > struct sched_entity *next; > > > struct rq *rq = lrq_rq(lrq); > > > u64 now = __rq_clock(rq); > > > > > >+ /* replay load smoothening …
creator: Dmitry Adamushko
date: 2007-06-12T12:23:38-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On Tue, Jun 12, 2007 at 02:23:38PM +0200, Dmitry Adamushko wrote: > >mm .. > > > > exec_delta64 = this_lrq->delta_exec_clock + 1; > > this_lrq->delta_exec_clock = 0; > > > >So exec_delta64 (and fair_delta64) should be min 1 in successive calls. > >How can that lead to this_load = 0? > > just substitute {exec,fair}_delta == 1 in the following code: > > tmp64 = SCHED_LOAD_SCALE * exec_delta64; > do_div(tmp64, fair_delta); > tmp64 *= exec_delta64; > do_div(tmp64, TICK_NSEC); > this_load = (unsigned long)tmp64; > > we'd get > > tmp64 = 1024 * 1; > tmp64 =/ 1; > tmp64 *= 1; > tmp64 /= 1000000; > > as a result, this_load = 1024/1000000; which is 0 (no floating point calc.). Ok .. But isn't that the same result we would have obtained anyways had we called update_load_fair() on all lrq's on every timer tick? If a user's lrq was inactive for several ticks, then its exec_delta will be seen as zero for those several ticks, which means we would compute its 'this_load' to be zero as well for those several ticks? Basically what I want to know is, are we sacrificing any accuracy here because of "deferring" smoothening of cpu_load for a (inactive) lrq (apart from the inaccurate figure used during load_balance as you point out below). > >The idea behind 'replay lost ticks' is to avoid load smoothening of > >-every- lrq -every- tick. Lets say that there are ten lrqs > >(corresponding to ten different users). We load smoothen only the currently > >active lrq (whose task is currently running). > > The raw idea behind update_load_fair() is that it evaluates the > run-time history between 2 consequent calls to it (which is now at > timer freq. --- that's a sapling period). So if you call > update_fair_load() in a loop, the sampling period is actually an > interval between 2 consequent calls. IOW, you can't say "3 ticks were > lost" so at first evaluate the load for the first tick, then the > second one, etc. ... Assuming the lrq was inactive for all those 3 ticks and became active at 4th…
creator: Srivatsa Vaddagiri
date: 2007-06-12T13:30:45-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On 12/06/07, Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote: > > [ ... ] > > > > just substitute {exec,fair}_delta == 1 in the following code: > > > > tmp64 = SCHED_LOAD_SCALE * exec_delta64; > > do_div(tmp64, fair_delta); > > tmp64 *= exec_delta64; > > do_div(tmp64, TICK_NSEC); > > this_load = (unsigned long)tmp64; > > > > we'd get > > > > tmp64 = 1024 * 1; > > tmp64 =/ 1; > > tmp64 *= 1; > > tmp64 /= 1000000; > > > > as a result, this_load = 1024/1000000; which is 0 (no floating point calc.). > > Ok .. > > But isn't that the same result we would have obtained anyways had we > called update_load_fair() on all lrq's on every timer tick? If a user's > lrq was inactive for several ticks, then its exec_delta will be seen as > zero for those several ticks, which means we would compute its 'this_load' to be > zero as well for those several ticks? Yeah.. seems to be so. But let's consider whether these 'inactive ticks' are really inactive [1] : The fact that user's tasks are not active at the moment of a timer interrupt doesn't mean they were not active _during_ the last tick. That's why another approach in update_load_fair() which doesn't depend on a snapshot of rq->raw_weighted_load at timer tick's time. I guess, we'd lose this with 'inactive ticks', right? ok, maybe it's not that important for per-user cpu_load, duno at the moment. > > Basically what I want to know is, are we sacrificing any accuracy here > because of "deferring" smoothening of cpu_load for a (inactive) lrq > (apart from the inaccurate figure used during load_balance as you point > out below). At least, we are getting some inaccuracy (not in a generic case though) due to the if (exec_delta64 > (u64)TICK_NSEC) exec_delta64 = (u64)TICK_NSEC; [*] in update_load_fair().. and that's smth I want to try changing... > > Assuming the lrq was inactive for all those 3 ticks and became active at > 4th tick, would the end result of cpu_load (as obtained in my code) be > any different than calling update_load_f…
creator: Dmitry Adamushko
date: 2007-06-12T14:31:38-00:00

Re: [RFC][PATCH 4/6] Fix (bad?) interactions between SCHED_RT and SCHED_NORMAL tasks
type: item
description: On Tue, Jun 12, 2007 at 04:31:38PM +0200, Dmitry Adamushko wrote: > >But isn't that the same result we would have obtained anyways had we > >called update_load_fair() on all lrq's on every timer tick? If a user's > >lrq was inactive for several ticks, then its exec_delta will be seen as > >zero for those several ticks, which means we would compute its 'this_load' > >to be > >zero as well for those several ticks? > > Yeah.. seems to be so. But let's consider whether these 'inactive ticks' are > really inactive [1] : > > The fact that user's tasks are not active at the moment of a timer > interrupt doesn't mean > they were not active _during_ the last tick. sure > That's why another > approach in update_load_fair() which doesn't depend on a snapshot of > rq->raw_weighted_load > at timer tick's time. I guess, we'd lose this with 'inactive ticks', > right? Sorry this is not clear. We'd lose what with 'inactive' ticks? If you are referring to the delta execution time a user's lrq consumed in the middle of a tick and whether we would lose them during subsequent update_load(), the answer IMO is no. Becasue put_prev_task_fair() would account for the small delta execution time when the task/lrq got descheduled. > ok, maybe > it's not that important for per-user cpu_load, duno at the moment. I would say any lossy accounting would be bad in long run. If you think put_prev_task_fair()->update_curr() still leaves open some problem, I would be interested in knowing that. > >Basically what I want to know is, are we sacrificing any accuracy here > >because of "deferring" smoothening of cpu_load for a (inactive) lrq > >(apart from the inaccurate figure used during load_balance as you point > >out below). > > At least, we are getting some inaccuracy (not in a generic case > though) due to the > > if (exec_delta64 > (u64)TICK_NSEC) > exec_delta64 = (u64)TICK_NSEC; [*] > > in update_load_fair().. If that is a problem (and I tend to agree that it is), then it is not unique to group lrq …
creator: Srivatsa Vaddagiri
date: 2007-06-12T15:43:32-00:00

Re: [RFC][PATCH 5/6] core changes for group fairness
type: item
description: On Wed, Jun 13, 2007 at 10:56:06PM +0200, Dmitry Adamushko wrote: > >+static int balance_tasks(struct rq *this_rq, int this_cpu, struct rq > >*busiest, > >+ unsigned long max_nr_move, unsigned long > >max_load_move, > >+ struct sched_domain *sd, enum idle_type idle, > >+ int *all_pinned, unsigned long *load_moved, > >+ int this_best_prio, int best_prio, int > >best_prio_seen, > >+ void *iterator_arg, > >+ struct task_struct *(*iterator_start)(void *arg), > >+ struct task_struct *(*iterator_next)(void *arg)); > > IMHO, it looks a bit frightening :) I agree :) It is taking (ooops) 15 args (8 perhaps was the previous record in sched.c (move_tasks)! > maybe it would be possible to > create a structure that combines some relevant argumens .. at least, > the last 3 ones. How does this look? struct balance_tasks_args { struct rq *this_rq, struct rq *busiest; unsigned long max_nr_move, unsigned long max_load_move; struct sched_domain *sd, enum idle_type idle; int this_best_prio, best_prio, best_prio_seen; int *all_pinned; unsigned long *load_moved; void *iterator_arg; struct task_struct *(*iterator_start)(void *arg); struct task_struct *(*iterator_next)(void *arg)); }; static int balance_tasks(struct balance_tasks_args *arg); [ down to one argument now! ] ? I will try this in my next iteration .. > >-static int move_tasks(struct rq *this_rq, int this_cpu, struct rq > >*busiest, > >+static int balance_tasks(struct rq *this_rq, int this_cpu, struct rq > >*busiest, > > unsigned long max_nr_move, unsigned long > > max_load_move, > > struct sched_domain *sd, enum idle_type idle, > >- int *all_pinned) > >+ int *all_pinned, unsigned long *load_moved, > >+ int this_best_prio, int best_prio, int > >best_prio_seen, > >+ void *iterator_arg, > >+ struct task_struct *(*iterator_start)(void *arg), > >+ struct task_struct *(*iterator_next)(void *arg)) > > I think, there is a possible problem here. If I'm not complete wrong, > this function (move_tasks() in the current mainline) can move m…
creator: Srivatsa Vaddagiri
date: 2007-06-14T12:06:05-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: Ingo Molnar wrote: > i'd still like to hear back from Kirill & co whether this framework is > flexible enough for their work (OpenVZ, etc.) too. My IMHO is that so far the proposed group scheduler doesn't look ready/suitable. We need to have a working SMP version before it will be clear whether the whole approach is good and works correct on variety of load patterns. Thanks, Kirill _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: dev
date: 2007-06-15T12:46:13-00:00

Re: [RFC][PATCH 0/6] Add group fairness to CFS - v1
type: item
description: On Fri, Jun 15, 2007 at 04:46:13PM +0400, Kirill Korotaev wrote: > Ingo Molnar wrote: > > > i'd still like to hear back from Kirill & co whether this framework is > > flexible enough for their work (OpenVZ, etc.) too. > > My IMHO is that so far the proposed group scheduler doesn't look ready/suitable. Hi Kirill, Yes its work-in-progress and hence is not ready/fully-functional (yet). The patches I posted last gives an idea of the direction it is heading. For ex: http://lkml.org/lkml/2007/6/11/162 and http://lkml.org/lkml/2007/5/25/146 gives an idea of how SMP load balance will works. IMHO the nice thing about this approach is it (re)uses lot of code in scheduler which is there already to achieve fairness between tasks and higher schedulable elements (users/containers etc). Also with CFS engine's precise nanosecond accurate accounting and time-sorted list of tasks/entities, I feel we will get much tighter control over distribution of CPU between tasks/users/containers. > We need to have a working SMP version before it will be clear > whether the whole approach is good and works correct on variety of load patterns. If you have any headsup thoughts on areas/workloads where this may pose problems for container/user scheduling, I would be glad to hear them. Otherwise I would greatly wellcome any help in developing/reviewing these patches which meets both our goals! -- Regards, vatsa _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Srivatsa Vaddagiri
date: 2007-06-15T14:06:45-00:00