[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070406191806.GA15291@elte.hu>
Date: Fri, 6 Apr 2007 21:18:06 +0200
From: Ingo Molnar <mingo@...e.hu>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Oleg Nesterov <oleg@...sign.ru>, Robin Holt <holt@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Chris Snook <csnook@...hat.com>, linux-kernel@...r.kernel.org,
Jack Steiner <steiner@...ricas.sgi.com>
Subject: [patch] sched: get rid of p->children use in show_task()
* Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Ingo Molnar <mingo@...e.hu> writes:
>
> > no. Two _completely separate_ lists.
> >
> > i.e. a to-be-reaped task will still be on the main list _too_. The
> > main list is for all the PID semantics rules. The reap-list is just
> > for wait4() processing. The two would be completely separate.
>
> And what pray tell except for heuristics is the list of children used
> for?
yeah - by all means get rid of it, but first separate the data
structures along uses. Then all the 'why should we iterate two lists in
sequence' questions vanish.
> I could find a use in the scheduler (oldest_child and younger/older_sibling).
this can be zapped today. The patch below does it - the scheduler use
was purely historic. oldest_child/older_sibling used to have a role but
it has none today.
> I could find a use in mm/oom_kill.
hm, this use is pretty valid although not user-detectable.
> I could find a use in irixsig where it roles it's own version of
> wait4.
zappable too.
> Perhaps I was blind but that was about it.
>
> I didn't see the child list implementing any semantics we really care
> about to user space.
i think you are right.
Ingo
Subject: [patch] sched: get rid of p->children use in show_task()
From: Ingo Molnar <mingo@...e.hu>
the p->parent PID printout gives us all the information about the
task tree that we need - the eldest_child()/older_sibling()/
younger_sibling() printouts are mostly historic and i do not
remember ever having used those fields. (IMO in fact they confuse
the SysRq-T output.) So remove them.
This code has sentimental value though, those fields and
printouts are one of the oldest ones still surviving from
Linux v0.95's kernel/sched.c:
if (p->p_ysptr || p->p_osptr)
printk(" Younger sib=%d, older sib=%d\n\r",
p->p_ysptr ? p->p_ysptr->pid : -1,
p->p_osptr ? p->p_osptr->pid : -1);
else
printk("\n\r");
written 15 years ago, in early 1992.
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/sched.c | 35 +----------------------------------
1 file changed, 1 insertion(+), 34 deletions(-)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4687,27 +4687,6 @@ out_unlock:
return retval;
}
-static inline struct task_struct *eldest_child(struct task_struct *p)
-{
- if (list_empty(&p->children))
- return NULL;
- return list_entry(p->children.next,struct task_struct,sibling);
-}
-
-static inline struct task_struct *older_sibling(struct task_struct *p)
-{
- if (p->sibling.prev==&p->parent->children)
- return NULL;
- return list_entry(p->sibling.prev,struct task_struct,sibling);
-}
-
-static inline struct task_struct *younger_sibling(struct task_struct *p)
-{
- if (p->sibling.next==&p->parent->children)
- return NULL;
- return list_entry(p->sibling.next,struct task_struct,sibling);
-}
-
static const char stat_nam[] = "RSDTtZX";
static void show_task(struct task_struct *p)
@@ -4738,19 +4717,7 @@ static void show_task(struct task_struct
free = (unsigned long)n - (unsigned long)end_of_stack(p);
}
#endif
- printk("%5lu %5d %6d ", free, p->pid, p->parent->pid);
- if ((relative = eldest_child(p)))
- printk("%5d ", relative->pid);
- else
- printk(" ");
- if ((relative = younger_sibling(p)))
- printk("%7d", relative->pid);
- else
- printk(" ");
- if ((relative = older_sibling(p)))
- printk(" %5d", relative->pid);
- else
- printk(" ");
+ printk("%5lu %5d %6d", free, p->pid, p->parent->pid);
if (!p->mm)
printk(" (L-TLB)\n");
else
-
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