thread_reap_barrier()

[kib]

Summary

Add thread_reap_barrier(), that ensures that no threads are left in the zombie list which were not inspected by the all process walk. See comment for more correct description.
Use it to drop the global atomic counter of linuxkpi task structures, drain the allocations using thread_reap_barrier().

[• hselasky]

I'll give this patch a spin tomorrow. Thank you!

sys/kern/kern_thread.c

765

The task, "t", can be made static. taskqueue_enqueue() will handle any races?

How about draining taskqueue_thread instead of the tsleep() ?

[• hselasky]

sys/kern/kern_thread.c

765

See "taskqueue_drain(queue, &task)"

[kib]

sys/kern/kern_thread.c

765

I would be fine with the use of drain if the taskqueue thread for reapping was a dedicated thread. Since this is the system-global thread, I prefer to have per-request task and the wait for its execution.

Might be, changing reaper to the own thread would be indeed good change.

[markj]

It is pretty heavyweight but I can't see any major problems.

sys/kern/kern_thread.c

724

745

Is it really necessary to handle the is_bound case? This function also sleeps; most or maybe all users of sched_pin() should not sleep in pinned sections.

763

765

Is it dynamically allocated only because the thread stack may be swapped out while waiting?

769

Why is the pause so long?

[kib]

sys/kern/kern_thread.c

745

Dropped and switched to reuse most of the code from quisce_cpus()

765

Exactly, and I do not want to PHOLD() current process.

[kib]

Fixed grammar.
Reuse quisce_cpus() adding PDROP flag.
Reduce tsleep timeout in thread_reap_barrier().

[• hselasky]

sys/kern/kern_thread.c

750

Why are you not using taskqueue_drain() here?

[kib]

sys/kern/kern_thread.c

750

I answered this in my previous reply to the similar question from you.

[• hselasky]

I would be fine with the use of drain if the taskqueue thread for reapping was a dedicated thread. Since this is the system-global thread, I prefer to have per-request task and the wait for its execution.

Are you worried about deadlock? Won't that happen anyway?

[kib]

In D30468#685718, @hselasky wrote:

I would be fine with the use of drain if the taskqueue thread for reapping was a dedicated thread. Since this is the system-global thread, I prefer to have per-request task and the wait for its execution.

Are you worried about deadlock? Won't that happen anyway?

It is not deadlock, more like livelock, and no, I do not believe that it could occur. On the other hand, it does incur arbitrary and undeserved delay on thread_reap_barrier() callers.

I consider this KPI to be useful outside the context of LKPI module, so I want it to be somehow precise.

[• hselasky]

It is not deadlock, more like livelock, and no, I do not believe that it could occur.

Can you describe this live-lock? I don't understand why draining a task would live lock?

--HPS

[• hselasky]

FYI: The taskqueue drain function only drains one task, not the whole queue!

[kib]

Use taskqueue_drain().