lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Dec 2010 18:38:18 +0530
From:	Bharata B Rao <bharata.rao@...il.com>
To:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	mathieu.desnoyers@...icios.com, torvalds@...ux-foundation.org,
	a.p.zijlstra@...llo.nl, efault@....de, pjt@...gle.com,
	markus@...ppelsdorf.de, tglx@...utronix.de, oleg@...hat.com,
	mingo@...e.hu
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched: Add 'autogroup' scheduling feature:
 automated per session task groups

On Tue, Nov 30, 2010 at 9:09 PM, tip-bot for Mike Galbraith
<efault@....de> wrote:
> Commit-ID:  5091faa449ee0b7d73bc296a93bca9540fc51d0a
> Gitweb:     http://git.kernel.org/tip/5091faa449ee0b7d73bc296a93bca9540fc51d0a
> Author:     Mike Galbraith <efault@....de>
> AuthorDate: Tue, 30 Nov 2010 14:18:03 +0100
> Committer:  Ingo Molnar <mingo@...e.hu>
> CommitDate: Tue, 30 Nov 2010 16:03:35 +0100
>
> sched: Add 'autogroup' scheduling feature: automated per session task groups
>
> diff --git a/kernel/sched_debug.c b/kernel/sched_debug.c
> index e95b774..1dfae3d 100644
> --- a/kernel/sched_debug.c
> +++ b/kernel/sched_debug.c
> @@ -54,8 +54,7 @@ static unsigned long nsec_low(unsigned long long nsec)
>  #define SPLIT_NS(x) nsec_high(x), nsec_low(x)
>
>  #ifdef CONFIG_FAIR_GROUP_SCHED
> -static void print_cfs_group_stats(struct seq_file *m, int cpu,
> -               struct task_group *tg)
> +static void print_cfs_group_stats(struct seq_file *m, int cpu, struct task_group *tg)
>  {
>        struct sched_entity *se = tg->se[cpu];
>        if (!se)
> @@ -110,16 +109,6 @@ print_task(struct seq_file *m, struct rq *rq, struct task_struct *p)
>                0LL, 0LL, 0LL, 0L, 0LL, 0L, 0LL, 0L);
>  #endif
>
> -#ifdef CONFIG_CGROUP_SCHED
> -       {
> -               char path[64];
> -
> -               rcu_read_lock();
> -               cgroup_path(task_group(p)->css.cgroup, path, sizeof(path));
> -               rcu_read_unlock();
> -               SEQ_printf(m, " %s", path);
> -       }
> -#endif
>        SEQ_printf(m, "\n");
>  }
>
> @@ -147,19 +136,6 @@ static void print_rq(struct seq_file *m, struct rq *rq, int rq_cpu)
>        read_unlock_irqrestore(&tasklist_lock, flags);
>  }
>
> -#if defined(CONFIG_CGROUP_SCHED) && \
> -       (defined(CONFIG_FAIR_GROUP_SCHED) || defined(CONFIG_RT_GROUP_SCHED))
> -static void task_group_path(struct task_group *tg, char *buf, int buflen)
> -{
> -       /* may be NULL if the underlying cgroup isn't fully-created yet */
> -       if (!tg->css.cgroup) {
> -               buf[0] = '\0';
> -               return;
> -       }
> -       cgroup_path(tg->css.cgroup, buf, buflen);
> -}
> -#endif
> -
>  void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
>  {
>        s64 MIN_vruntime = -1, min_vruntime, max_vruntime = -1,
> @@ -168,16 +144,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
>        struct sched_entity *last;
>        unsigned long flags;
>
> -#if defined(CONFIG_CGROUP_SCHED) && defined(CONFIG_FAIR_GROUP_SCHED)
> -       char path[128];
> -       struct task_group *tg = cfs_rq->tg;
> -
> -       task_group_path(tg, path, sizeof(path));
> -
> -       SEQ_printf(m, "\ncfs_rq[%d]:%s\n", cpu, path);
> -#else
>        SEQ_printf(m, "\ncfs_rq[%d]:\n", cpu);
> -#endif
>        SEQ_printf(m, "  .%-30s: %Ld.%06ld\n", "exec_clock",
>                        SPLIT_NS(cfs_rq->exec_clock));
>
> @@ -215,7 +182,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
>        SEQ_printf(m, "  .%-30s: %ld\n", "load_contrib",
>                        cfs_rq->load_contribution);
>        SEQ_printf(m, "  .%-30s: %d\n", "load_tg",
> -                       atomic_read(&tg->load_weight));
> +                       atomic_read(&cfs_rq->tg->load_weight));
>  #endif
>
>        print_cfs_group_stats(m, cpu, cfs_rq->tg);
> @@ -224,17 +191,7 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)
>
>  void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq)
>  {
> -#if defined(CONFIG_CGROUP_SCHED) && defined(CONFIG_RT_GROUP_SCHED)
> -       char path[128];
> -       struct task_group *tg = rt_rq->tg;
> -
> -       task_group_path(tg, path, sizeof(path));
> -
> -       SEQ_printf(m, "\nrt_rq[%d]:%s\n", cpu, path);
> -#else
>        SEQ_printf(m, "\nrt_rq[%d]:\n", cpu);
> -#endif
> -

The above change as well as the recent changes due to tg_shares_up
improvements have two (undesirable ?) side effects on
/proc/sched_debug output.

The autogroup patchset removes the display of cgroup name from
sched_debug output.

On a 16 CPU system, with 2 groups having one task each and one task in
root group, the difference in o/p appears like this:

$ grep while1 sched_debug-2.6.37-rc5
R         while1  2208     13610.855787      1960   120
13610.855787     19272.857661         0.000000 /2
R         while1  2207     20255.605110      3160   120
20255.605110     31572.634065         0.000000 /1
R         while1  2209     63913.721827      1273   120
63913.721827     12604.411880         0.000000 /

$ grep while1 sched_debug-2.6.37-rc5-tip
R         while1  2173     17603.479529      2754   120
17603.479529     25818.279858         4.560010
R         while1  2174     11435.667691      1669   120
11435.667691     16456.476663         0.000000
R         while1  2175     10074.709060      1019   120
10074.709060     10075.915495         0.000000

So you can see in the latter case, it becomes difficult to see which
task belongs to which group.

The group names are also missing from per-CPU rq information. Hence in
the above example of 2 groups, I see 2 blocks of data for 2 cfs_rqs,
but it is not possible to know which group they represent.

Also, with tg_shares_up improvements, the leaf cfs_rqs are maintained
on rq->leaf_cfs_rq_list only if they carry any load. But the code to
display cfs_rq information for sched_debug isn't updated and hence
information from a few cfs_rqs are missing from sched_debug.

$ grep cfs_rq sched_debug-2.6.37-rc5
cfs_rq[0]:/2
cfs_rq[0]:/1
cfs_rq[0]:/
cfs_rq[1]:/2
cfs_rq[1]:/1
cfs_rq[1]:/
cfs_rq[2]:/2
cfs_rq[2]:/1
cfs_rq[2]:/
cfs_rq[3]:/2
cfs_rq[3]:/1
cfs_rq[3]:/
cfs_rq[4]:/2
cfs_rq[4]:/1
cfs_rq[4]:/
cfs_rq[5]:/2
cfs_rq[5]:/1
cfs_rq[5]:/
cfs_rq[6]:/2
cfs_rq[6]:/1
cfs_rq[6]:/
cfs_rq[7]:/2
cfs_rq[7]:/1
cfs_rq[7]:/
cfs_rq[8]:/2
cfs_rq[8]:/1
cfs_rq[8]:/
cfs_rq[9]:/2
cfs_rq[9]:/1
cfs_rq[9]:/
cfs_rq[10]:/2
cfs_rq[10]:/1
cfs_rq[10]:/
cfs_rq[11]:/2
cfs_rq[11]:/1
cfs_rq[11]:/
cfs_rq[12]:/2
cfs_rq[12]:/1
cfs_rq[12]:/
cfs_rq[13]:/2
cfs_rq[13]:/1
cfs_rq[13]:/
cfs_rq[14]:/2
cfs_rq[14]:/1
cfs_rq[14]:/
cfs_rq[15]:/2
cfs_rq[15]:/1
cfs_rq[15]:/

$ grep cfs_rq sched_debug-2.6.37-rc5-tip
cfs_rq[0]:
cfs_rq[0]:
cfs_rq[1]:
cfs_rq[2]:
cfs_rq[3]:
cfs_rq[4]:
cfs_rq[4]:
cfs_rq[5]:
cfs_rq[5]:
cfs_rq[6]:
cfs_rq[7]:
cfs_rq[8]:
cfs_rq[9]:
cfs_rq[10]:
cfs_rq[11]:
cfs_rq[11]:
cfs_rq[12]:
cfs_rq[12]:
cfs_rq[13]:
cfs_rq[13]:
cfs_rq[14]:
cfs_rq[14]:
cfs_rq[15]:
cfs_rq[15]:

Regards,
Bharata.
--
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