[patch] sched: get rid of p->children use in show_task()

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Ingo Molnar
Date: Friday, April 6, 2007 - 12:18 pm

* Eric W. Biederman <ebiederm@xmission.com> wrote:


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.


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.


hm, this use is pretty valid although not user-detectable.


zappable too.


i think you are right.

	Ingo

Subject: [patch] sched: get rid of p->children use in show_task()
From: Ingo Molnar <mingo@elte.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@elte.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
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Thu Apr 5, 7:15 pm)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 8:38 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 11:02 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 11:04 am)
Re: init's children list is long and slows reaping children., Christoph Hellwig, (Fri Apr 6, 11:05 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 11:30 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 11:56 am)
[patch] sched: get rid of p->children use in show_task(), Ingo Molnar, (Fri Apr 6, 12:18 pm)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Fri Apr 6, 12:39 pm)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Mon Apr 9, 1:00 pm)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Mon Apr 9, 5:48 pm)
Re: init's children list is long and slows reaping children., Alexey Dobriyan, (Mon Apr 9, 10:07 pm)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Tue Apr 10, 7:51 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Tue Apr 10, 8:00 am)
[PATCH] Only send pdeath_signal when getppid changes., Eric W. Biederman, (Tue Apr 10, 8:16 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Tue Apr 10, 8:22 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Tue Apr 10, 9:17 am)
Re: [PATCH] Only send pdeath_signal when getppid changes., Oleg Nesterov, (Tue Apr 10, 9:37 am)
Re: [PATCH] Only send pdeath_signal when getppid changes., Eric W. Biederman, (Tue Apr 10, 10:41 am)
Re: [PATCH] Only send pdeath_signal when getppid changes., Roland McGrath, (Tue Apr 10, 10:48 am)
Re: init's children list is long and slows reaping children., Davide Libenzi, (Tue Apr 10, 12:17 pm)
Re: [PATCH] Only send pdeath_signal when getppid changes., Albert Cahalan, (Tue Apr 10, 8:17 pm)
[patch] uninline remove/add_parent() APIs, Ingo Molnar, (Tue Apr 10, 11:20 pm)
Re: [patch] uninline remove/add_parent() APIs, Eric W. Biederman, (Wed Apr 11, 12:00 am)
Re: init's children list is long and slows reaping children., Eric W. Biederman, (Wed Apr 11, 1:17 pm)
Re: [patch] uninline remove/add_parent() APIs, Andrew Morton, (Wed Apr 11, 3:06 pm)
Re: [patch] uninline remove/add_parent() APIs, Eric W. Biederman, (Thu Apr 12, 3:45 am)
Re: [patch] uninline remove/add_parent() APIs, Roland McGrath, (Thu Apr 12, 3:50 pm)