Replace PID bitmap allocation with IDR API

This patch replaces the current bitmap implemetation for Process ID allocation. Functions that are no longer required, for example, free_pidmap(), alloc_pidmap(), etc. are removed. The rest of the functions are modified to use the IDR API. The change was made to make the PID allocation less complex by replacing custom code with calls to generic API.

arch/powerpc/platforms/cell/spufs/sched.c +2 -3

@@ -240,17 +230,18 @@ void zap_pid_ns_processes(struct pid_namespace
 *pid_ns)
  	 *
  	 */
  	read_lock(&tasklist_lock);
-	nr = next_pidmap(pid_ns, 1);
-	while (nr > 0) {
-		rcu_read_lock();
+	pid = idr_get_next(&pid_ns->idr, &nr);
+	while (pid) {

arch/powerpc/platforms/cell/spufs/sched.c +0 -3

-		task = pid_task(find_vpid(nr), PIDTYPE_PID);
-		if (task && !__fatal_signal_pending(task))
-			send_sig_info(SIGKILL, SEND_SIG_FORCED,

task);

arch/powerpc/platforms/cell/spufs/sched.c +1 -0

+		rcu_read_lock();

arch/powerpc/platforms/cell/spufs/sched.c +4 -0

+		idr_for_each_entry_continue(&pid_ns->idr, pid, nr) {
+			task = pid_task(pid, PIDTYPE_PID);
+			if (task && !__fatal_signal_pending(task))
+				send_sig_info(SIGKILL,

SEND_SIG_FORCED, task);

arch/powerpc/platforms/cell/spufs/sched.c +1 -0

+		}

  rcu_read_unlock();

arch/powerpc/platforms/cell/spufs/sched.c +0 -1

-		nr = next_pidmap(pid_ns, nr);

  }
  read_unlock(&tasklist_lock);

Quoted 25 lines

kernel/pid_namespace.c +2 -3

@@ -240,17 +230,18 @@ void zap_pid_ns_processes(struct pid_namespace
 *pid_ns)
  	 *
  	 */
  	read_lock(&tasklist_lock);
-	nr = next_pidmap(pid_ns, 1);
-	while (nr > 0) {
-		rcu_read_lock();
+	pid = idr_get_next(&pid_ns->idr, &nr);
+	while (pid) {

kernel/pid_namespace.c +0 -3

-		task = pid_task(find_vpid(nr), PIDTYPE_PID);
-		if (task && !__fatal_signal_pending(task))
-			send_sig_info(SIGKILL, SEND_SIG_FORCED,

task);

kernel/pid_namespace.c +1 -0

+		rcu_read_lock();

kernel/pid_namespace.c +4 -0

+		idr_for_each_entry_continue(&pid_ns->idr, pid, nr) {
+			task = pid_task(pid, PIDTYPE_PID);
+			if (task && !__fatal_signal_pending(task))
+				send_sig_info(SIGKILL,

SEND_SIG_FORCED, task);

kernel/pid_namespace.c +1 -0

+		}

  rcu_read_unlock();

Quoted 5 lines

kernel/pid_namespace.c +0 -1

-		nr = next_pidmap(pid_ns, nr);

  }
  read_unlock(&tasklist_lock);

I believe we should be fine with just the idr_for_each_entry_continue() surrounding the loop,

and not need the while (pid) around that.

That should still iterate over all the pids in the namespace, and simplify the code even more.

Quoted 26 lines · Rik van Riel

Quoted 26 lines

kernel/pid_namespace.c +8 -6

@@ -240,17 +230,18 @@ void zap_pid_ns_processes(struct pid_namespace
 *pid_ns)
     *
     */
    read_lock(&tasklist_lock);
-   nr = next_pidmap(pid_ns, 1);
-   while (nr > 0) {
-           rcu_read_lock();
+   pid = idr_get_next(&pid_ns->idr, &nr);
+   while (pid) {
 
-           task = pid_task(find_vpid(nr), PIDTYPE_PID);
-           if (task && !__fatal_signal_pending(task))
-                   send_sig_info(SIGKILL, SEND_SIG_FORCED,
 task);
+           rcu_read_lock();
 
+           idr_for_each_entry_continue(&pid_ns->idr, pid, nr) {
+                   task = pid_task(pid, PIDTYPE_PID);
+                   if (task && !__fatal_signal_pending(task))
+                           send_sig_info(SIGKILL,
 SEND_SIG_FORCED, task);
+           }
            rcu_read_unlock();
 

Quoted 7 lines

Quoted 4 lines

kernel/pid_namespace.c +0 -1

-           nr = next_pidmap(pid_ns, nr);

    }
    read_unlock(&tasklist_lock);

I believe we should be fine with just the idr_for_each_entry_continue() surrounding the loop,

Yes, and please move "nr = 2" close to idr_for_each_entry_continue() to make it clear why do we use _continue (to skip nr == 1).

Quoted 2 lines

and not need the while (pid) around that.

Quoted 2 lines

That should still iterate over all the pids in the namespace, and simplify the code even more.

And make this patch correct ;)

because currently it is wrong, zap_pid_ns_processes() won't kill the pid returned by the first idr_get_next().

Oleg.

Quoted 6 lines

And make this patch correct ;)

because currently it is wrong, zap_pid_ns_processes() won't kill the pid returned by the first idr_get_next().

Yes, I missed this. I can simply remove the idr_get_next() before the idr_for_each_continue and that will take care of it.

Quoted 6 lines · Gargi Sharma

This patch replaces the current bitmap implemetation for Process ID allocation. Functions that are no longer required, for example, free_pidmap(), alloc_pidmap(), etc. are removed. The rest of the functions are modified to use the IDR API. The change was made to make the PID allocation less complex by replacing custom code with calls to generic API.

I like where this is going. Just a few last comments from me :)

arch/powerpc/platforms/cell/spufs/sched.c static int show_spu_loadavg(struct seq_file *s, · line 1099

Quoted 11 lines

arch/powerpc/platforms/cell/spufs/sched.c +1 -1

@@ -1093,7 +1093,7 @@ static int show_spu_loadavg(struct seq_file *s,
 void *private)
              LOAD_INT(c), LOAD_FRAC(c),
              count_active_contexts(),
              atomic_read(&nr_spu_contexts),
-             task_active_pid_ns(current)->last_pid);
+             task_active_pid_ns(current)->idr.idr_next-1);
      return 0;
 }

Everywhere you use idr.idr_next or idr->idr_next directly, you could use idr_get_cursor(idr) instead, exposing less of the IDR internals to the rest of the code.

Quoted 27 lines

arch/powerpc/platforms/cell/spufs/sched.c +8 -7

@@ -240,17 +230,18 @@ void zap_pid_ns_processes(struct pid_namespace
 *pid_ns)
       *
       */
      read_lock(&tasklist_lock);
-     nr = next_pidmap(pid_ns, 1);
-     while (nr > 0) {
-             rcu_read_lock();
+     pid = idr_get_next(&pid_ns->idr, &nr);
+     while (pid) {
 
-             task = pid_task(find_vpid(nr), PIDTYPE_PID);
-             if (task && !__fatal_signal_pending(task))
-                     send_sig_info(SIGKILL, SEND_SIG_FORCED,
 task);
+             rcu_read_lock();
 
+             idr_for_each_entry_continue(&pid_ns->idr, pid, nr) {
+                     task = pid_task(pid, PIDTYPE_PID);
+                     if (task && !__fatal_signal_pending(task))
+                             send_sig_info(SIGKILL,
 SEND_SIG_FORCED, task);
+             }
              rcu_read_unlock();
 
-             nr = next_pidmap(pid_ns, nr);

Quoted 3 lines

      }
      read_unlock(&tasklist_lock);

I believe we should be fine with just the idr_for_each_entry_continue() surrounding the loop, and not need the while (pid) around that.

That should still iterate over all the pids in the namespace, and simplify the code even more.

You have done a great job understanding some complicated code, and simplifying it during your Outreachy internship.

--
All Rights Reversed.

kernel/pid.c +16 -1

@@ -309,7 +168,22 @@ struct pid *alloc_pid(struct pid_namespace *ns)
 	tmp = ns;
 	pid->level = ns->level;
 	for (i = ns->level; i >= 0; i--) {
-		nr = alloc_pidmap(tmp);
+		int pid_min = 1;
+		idr_preload(GFP_KERNEL);
+		spin_lock_irq(&pidmap_lock);
+
+		/*
+		 * init really needs pid 1, but after reaching the maximum
+		 * wrap back to RESERVED_PIDS
+		 */
+		if (tmp->idr.idr_next > RESERVED_PIDS)
+			pid_min = RESERVED_PIDS;
+
+		nr = idr_alloc_cyclic(&tmp->idr, pid, pid_min,
+				      pid_max, GFP_ATOMIC);
+		spin_unlock_irq(&pidmap_lock);
+		idr_preload_end();
+
 		if (nr < 0) {
 			retval = nr;
 			goto out_free;

Review

Quoted 2 lines

(quoted diff) +1 -1

-             task_active_pid_ns(current)->last_pid);
+             task_active_pid_ns(current)->idr.idr_next-1);

I think we want a well documented helper for this pattern instead of poking into the internals.

Also is last - 1 always the correct answer? Even with idr_alloc_cyclic we could wrap around, couldn't we?

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines

-             task_active_pid_ns(current)->last_pid); +             task_active_pid_ns(current)->idr.idr_next-1);

I think we want a well documented helper for this pattern instead of poking into the internals.

idr_get_cursor() get can be used instead of idr.idr_next, so that we do not
expose the internals.

Quoted 4 lines

Also is last - 1 always the correct answer?  Even with idr_alloc_cyclic
we could wrap around, couldn't we?

-1 will be incorrect when the pids wrap around. Should we go back to setting up last_pid as it was done before? Or should we use idr_get_cursor
and determine if pid was rolled over and then perform necessary action?

Review

Quoted 2 lines

(quoted diff) +1 -1

-		task_active_pid_ns(current)->last_pid);
+		task_active_pid_ns(current)->idr.idr_next-1);

I think we want a well documented helper for this pattern instead of poking into the internals.

Also is last - 1 always the correct answer?  Even with idr_alloc_cyclic
we could wrap around, couldn't we?

kernel/pid.c int pid_max = PID_MAX_DEFAULT; · line 59

Quoted 4 lines · Gargi Sharma

kernel/pid.c +0 -3

-#define find_next_offset(map, off)					\
-		find_next_zero_bit((map)->page, BITS_PER_PAGE, off)
-

this should go into the previous patch, but this is minor...

kernel/pid.c struct pid *alloc_pid(struct pid_namespace *ns) · line 206

Quoted 12 lines

kernel/pid.c +2 -4

@@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace *ns)
 
 	upid = pid->numbers + ns->level;
 	spin_lock_irq(&pidmap_lock);
-	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
+	if (!(ns->pid_allocated & PIDNS_ADDING))
 		goto out_unlock;
 	for ( ; upid >= pid->numbers; --upid) {
-		hlist_add_head_rcu(&upid->pid_chain,
-				&pid_hash[pid_hashfn(upid->nr, upid->ns)]);
-		upid->ns->nr_hashed++;
+		upid->ns->pid_allocated++;

No, this is wrong.

It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and increment pid_allocated, once we call idr_alloc_cyclic() this pid is already "hashed" in that it can be found by find_pid_ns() with this patch applied.

And of course, it is too late to do atomic_set(&pid->count, 1) and initialize pid->tasks[type] lists by the same reason.

Oleg.

If I was not clear...

in short, after this patch the very first idr_alloc_cyclic() is already wrong. Because, once again, the new not-fully-initialized pid can be found by find_pid_ns().

perhaps you should chane the previous patch to do idr_alloc_cyclic(ptr = NULL) and use idr_replace() in this patch after the PIDNS_HASH_ADDING check.

And I just noticed you didn't cc Eric Biederman <[email protected]>, please do next time.

Quoted 32 lines · Gargi Sharma

kernel/pid.c int pid_max = PID_MAX_DEFAULT; · line 59

Quoted 4 lines

kernel/pid.c +0 -3

-#define find_next_offset(map, off)                                 \
-           find_next_zero_bit((map)->page, BITS_PER_PAGE, off)
-

this should go into the previous patch, but this is minor...

kernel/pid.c struct pid *alloc_pid(struct pid_namespace *ns) · line 206

Quoted 12 lines

kernel/pid.c +2 -4

@@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace *ns)
 
    upid = pid->numbers + ns->level;
    spin_lock_irq(&pidmap_lock);
-   if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
+   if (!(ns->pid_allocated & PIDNS_ADDING))
            goto out_unlock;
    for ( ; upid >= pid->numbers; --upid) {
-           hlist_add_head_rcu(&upid->pid_chain,
-                           &pid_hash[pid_hashfn(upid->nr, upid->ns)]);
-           upid->ns->nr_hashed++;
+           upid->ns->pid_allocated++;

No, this is wrong.

It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and increment pid_allocated, once we call idr_alloc_cyclic() this pid is already "hashed" in that it can be found by find_pid_ns() with this patch applied.

And of course, it is too late to do atomic_set(&pid->count, 1) and initialize pid->tasks[type] lists by the same reason.

Oleg.

Quoted 5 lines · Oleg Nesterov

If I was not clear...

in short, after this patch the very first idr_alloc_cyclic() is already wrong. Because, once again, the new not-fully-initialized pid can be found by find_pid_ns().

If the PIDNS_ADDING check fails, I jump to the flag that performs this
while (++i <= ns->level)

                 idr_remove(&ns->idr, (pid->numbers + i)->nr);

So when find_pid_ns() is called, it will not find this pid.

Quoted 3 lines

perhaps you should chane the previous patch to do idr_alloc_cyclic(ptr = NULL) and use idr_replace() in this patch after the PIDNS_HASH_ADDING check.

I'm not sure if I understand this. Do we want to do this to make sure the pid namespace is
initialized before the first process enters into
the namespace? If yes,

how does idr_alloc_cyclic(ptr = NULL) help?

Quoted 6 lines · Gargi Sharma

-#define find_next_offset(map, off)
\

(quoted diff) +0 -1

-		find_next_zero_bit((map)->page, BITS_PER_PAGE,

off)
-

this should go into the previous patch, but this is minor...

Quoted 12 lines

(quoted diff) +0 -0

@@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace
 *ns)

  upid = pid->numbers + ns->level;
  spin_lock_irq(&pidmap_lock);

kernel/pid.c +1 -1

-	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
+	if (!(ns->pid_allocated & PIDNS_ADDING))

  goto out_unlock;
  for ( ; upid >= pid->numbers; --upid) {

(quoted diff) +0 -2

-		hlist_add_head_rcu(&upid->pid_chain,
-				&pid_hash[pid_hashfn(upid->nr,

upid->ns)]);

kernel/pid.c struct pid *alloc_pid(struct pid_namespace *ns) · line 206

Quoted 2 lines

kernel/pid.c +1 -1

-		upid->ns->nr_hashed++;
+		upid->ns->pid_allocated++;

No, this is wrong.

It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and increment pid_allocated,
once we call idr_alloc_cyclic() this pid is already "hashed" in that it can be found
by find_pid_ns() with this patch applied.

And of course, it is too late to do atomic_set(&pid->count, 1) and initialize
pid->tasks[type] lists by the same reason.

Quoted 36 lines · Oleg Nesterov

Quoted 7 lines · Gargi Sharma

-#define find_next_offset(map, off)

\

(quoted diff) +0 -1

-		find_next_zero_bit((map)->page, BITS_PER_PAGE,

off)
-

this should go into the previous patch, but this is minor...

Quoted 12 lines

(quoted diff) +0 -0

@@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace
 *ns)

  upid = pid->numbers + ns->level;
  spin_lock_irq(&pidmap_lock);

kernel/pid.c +1 -1

-	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
+	if (!(ns->pid_allocated & PIDNS_ADDING))

  goto out_unlock;
  for ( ; upid >= pid->numbers; --upid) {

(quoted diff) +0 -2

-		hlist_add_head_rcu(&upid->pid_chain,
-				&pid_hash[pid_hashfn(upid->nr,

upid->ns)]);

kernel/pid.c struct pid *alloc_pid(struct pid_namespace *ns) · line 206

Quoted 2 lines

kernel/pid.c +1 -1

-		upid->ns->nr_hashed++;
+		upid->ns->pid_allocated++;

No, this is wrong.

It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and increment
pid_allocated,
once we call idr_alloc_cyclic() this pid is already "hashed" in that
it can be found
by find_pid_ns() with this patch applied.

Quoted 3 lines

And of course, it is too late to do atomic_set(&pid->count, 1) and initialize
pid->tasks[type] lists by the same reason.

Hi Oleg,

Gargi and I are looking at that code, and trying to figure out exactly what needs to be done to make all of this correct.

We are thinking something along these lines:

3) First, check if this is a new namespace (PIDNS_ADDING), and do the call to pid_ns_prepare_proc, before we even call idr_alloc. Maybe something like:

   if (unlikely(ns->nr_allocated == PIDNS_ADDING)) { if (pid_ns_prepare_proc(ns)) { disable_pid_allocations(ns);
         goto out_free_ns;
   }

4) With pid_ns_prepare_proc out of the way, we can put all the code from below where the call to pid_ns_prepare_proc is now (except error handing) into the main loop of pid allocation, so we can do all that stuff under the pidmap_lock:

   for (i = ns->level; i >= 0; i--) {
       ...
       idr_alloc_cyclic(...)

       ns->nr_allocated++;
       ...
  }

Would that resolve your objection, or are we barking up the wrong tree?

Gargi and I are looking at that code, and trying to figure out exactly what needs to be done to make all of this correct.

2) With pid_ns_prepare_proc out of the way, we can put all the code from below where the call to pid_ns_prepare_proc is now (except error handing) into the main loop of pid allocation, so we can do all that stuff under the pidmap_lock:

   for (i = ns->level; i >= 0; i--) {
       ...
       idr_alloc_cyclic(...)
       get_pid_ns(ns);
       atomic_set(&pid->count, 1);
       for (...)
            INIT_HLIST_HEAD(...)
       ns->nr_allocated++;
       ...
  }

Hi Rik,

Quoted 3 lines · Rik van Riel

Gargi and I are looking at that code, and trying to figure out exactly what needs to be done to make all of this correct.

see another email I sent to Gargi a minute ago,

Quoted 5 lines

2) With pid_ns_prepare_proc out of the way, we can put all the code from below where the call to pid_ns_prepare_proc is now (except error handing) into the main loop of pid allocation, so we can do all that stuff under the pidmap_lock:

Quoted 10 lines

   for (i = ns->level; i >= 0; i--) {
       ...
       idr_alloc_cyclic(...)
       get_pid_ns(ns);
       atomic_set(&pid->count, 1);
       for (...)
            INIT_HLIST_HEAD(...)
       ns->nr_allocated++;
       ...
  }

I do not see how this can fix the problem with not-fully-initialized pid returned by find_pid_ns().

As for PIDNS_ADDING/PIDNS_HASH_ADDING, _perhaps_ we can cleanup this logic
a bit and do the check earlier, but imo this needs another/separate change.

I'd suggest to keep the current logic and the order of initialization and
just do

	for (i = ns->level; i >= 0; i--) {
		...

		// do not expose the new pid to find_pid_ns() until it
		// is fully initialized
		nr = idr_alloc_cyclic(&tmp->idr, /*pid*/ NULL, ...);
		...
	}

	...

	spin_lock_irq(&pidmap_lock);
	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
		goto out_unlock;
	for ( ; upid >= pid->numbers; --upid) {

(quoted diff) +0 -2

-		hlist_add_head_rcu(&upid->pid_chain,
-				&pid_hash[pid_hashfn(upid->nr, upid-

Quoted 1 line

ns)]);

(quoted diff) +2 -0

+		// finally make it visible to find_pid_ns()
+		idr_replace(upid->ns-idr, pid, upid->nr);

		upid->ns->nr_hashed++;
	}
	spin_unlock_irq(&pidmap_lock);

Or I missed something?

Quoted 54 lines · Oleg Nesterov

Hi Rik,

Quoted 3 lines · Rik van Riel

Gargi and I are looking at that code, and trying to figure out exactly what needs to be done to make all of this correct.

see another email I sent to Gargi a minute ago,

Quoted 5 lines

2) With pid_ns_prepare_proc out of the way, we can put all the code from below where the call to pid_ns_prepare_proc is now (except error handing) into the main loop of pid allocation, so we can do all that stuff under the pidmap_lock:

Quoted 10 lines

   for (i = ns->level; i >= 0; i--) {
       ...
       idr_alloc_cyclic(...)
       get_pid_ns(ns);
       atomic_set(&pid->count, 1);
       for (...)
            INIT_HLIST_HEAD(...)
       ns->nr_allocated++;
       ...
  }

I do not see how this can fix the problem with not-fully-initialized pid returned by find_pid_ns().

As for PIDNS_ADDING/PIDNS_HASH_ADDING, _perhaps_ we can cleanup this logic
a bit and do the check earlier, but imo this needs another/separate change.

I'd suggest to keep the current logic and the order of initialization and
just do

      for (i = ns->level; i >= 0; i--) {
              ...

              // do not expose the new pid to find_pid_ns() until it
              // is fully initialized
              nr = idr_alloc_cyclic(&tmp->idr, /*pid*/ NULL, ...);
              ...
      }

      ...

      spin_lock_irq(&pidmap_lock);
      if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
              goto out_unlock;
      for ( ; upid >= pid->numbers; --upid) {

(quoted diff) +0 -2

-             hlist_add_head_rcu(&upid->pid_chain,
-                             &pid_hash[pid_hashfn(upid->nr, upid-

Quoted 8 lines

Quoted 1 line

ns)]);

(quoted diff) +2 -0

+             // finally make it visible to find_pid_ns()
+             idr_replace(upid->ns-idr, pid, upid->nr);
              upid->ns->nr_hashed++;
      }
      spin_unlock_irq(&pidmap_lock);

Or I missed something?

You are right, that would both fix the problem, and keep the error paths relatively simple.

Gargi, what do you think?

--
All Rights Reversed.

This patch series replaces kernel bitmap implementation of PID allocation
with IDR API. These patches are written to simplify the kernel by replacing custom code with calls to generic code.

The following are the stats for pid and pid_namespace object files before and after the replacement. There is a noteworthy change between the IDR and bitmap implementation.

Before
text data bss dec hex filename
8447 3894 64 12405 3075 kernel/pid.o
After
text data bss dec hex filename
3301 304 0 3605 e15 kernel/pid.o

Before
text data bss dec hex filename
5692 1842 192 7726 1e2e kernel/pid_namespace.o
After
text data bss dec hex filename
2870 216 16 3102 c1e kernel/pid_namespace.o

There wasn't a considerable difference between the time required for allocation of PIDs to the processes.

From what Oleg has pointed out and from your the holes in your

---
Changes in v2:
- Removed redundant IDR function that was introduced in the previous patchset.
- Renamed PIDNS_HASH_ADDING
- Used idr_for_each_entry_continue()
- Used idr_find() to lookup pids

Gargi Sharma (2):
pid: Replace pid bitmap implementation with IDR API
pid: Remove pidhash

 arch/powerpc/platforms/cell/spufs/sched.c |   2 +-
 fs/proc/loadavg.c                         |   2 +-
 include/linux/init_task.h                 |   1 -
 include/linux/pid.h                       |   2 -
 include/linux/pid_namespace.h             |  18 +--
 init/main.c                               |   3 +-
 kernel/fork.c                             |   2 +-
 kernel/pid.c                              | 239 +++++-------------------------
 kernel/pid_namespace.c                    |  54 +++----
 9 files changed, 68 insertions(+), 255 deletions(-)

1000 processes that just sleep and sit around without doing anything(100 second sleep and then exit).

pstree with 10,000 processes
real    0m0.859s
user    0m0.536s
sys    0m0.172s

ps with 10,000 processes
real    0m0.918s
user    0m0.100s
sys    0m0.172s

Stats for calling readdir on /proc with 10,000 processes real    0m0.092s
user    0m0.000s
sys    0m0.020s

Quoted 13 lines · Gargi Sharma

1000 processes that just sleep and sit around without doing anything(100 second sleep and then exit).

pstree with 10,000 processes
real 0m0.859s
user 0m0.536s
sys 0m0.172s

ps with 10,000 processes
real 0m0.918s
user 0m0.100s
sys 0m0.172s

Quoted 4 lines

Stats for calling readdir on /proc with 10,000 processes
real 0m0.092s
user 0m0.000s
sys 0m0.020s

Is that with or without your patches?

How does it compare to a kernel with(out) your patches?

--
All Rights Reversed.

Quoted 13 lines · Gargi Sharma

1000 processes that just sleep and sit around without doing anything(100 second sleep and then exit).

pstree with 10,000 processes
real 0m0.859s
user 0m0.536s
sys 0m0.172s

ps with 10,000 processes
real 0m0.918s
user 0m0.100s
sys 0m0.172s

Quoted 4 lines

Stats for calling readdir on /proc with 10,000 processes
real 0m0.092s
user 0m0.000s
sys 0m0.020s

Is that with or without your patches?

How does it compare to a kernel with(out) your patches?

--
All Rights Reversed.

Quoted 8 lines · Rik van Riel

Quoted 2 lines · Gargi Sharma

1000 processes that just sleep and sit around without doing anything(100 second sleep and then exit).

Is that with or without your patches?

How does it compare to a kernel with(out) your patches?

Ah thanks for pointing this out. Those were without the patches. Here are the stats for easier comparison.

With Patches                 Without patches
pstree
real    0m0.542s            real    0m0.859s
user    0m0.335s           user    0m0.536s
sys    0m0.150s             sys    0m0.172s

ps
real    0m0.722s            real    0m0.918s
user    0m0.064s           user    0m0.100s
sys    0m0.162s             sys    0m0.172s

readdir
real    0m0.080s           real    0m0.092s
user    0m0.000s          user    0m0.000s
sys    0m0.021s            sys    0m0.020s