Page MenuHomeFreeBSD

thread_reap_barrier()
ClosedPublic

Authored by kib on May 26 2021, 2:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 29, 10:45 AM
Unknown Object (File)
Feb 15 2024, 8:11 PM
Unknown Object (File)
Feb 2 2024, 8:11 PM
Unknown Object (File)
Feb 1 2024, 9:34 PM
Unknown Object (File)
Feb 1 2024, 9:34 PM
Unknown Object (File)
Jan 27 2024, 6:23 PM
Unknown Object (File)
Jan 14 2024, 4:44 AM
Unknown Object (File)
Jan 9 2024, 7:47 PM

Details

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().

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.May 26 2021, 2:29 PM

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() ?

sys/kern/kern_thread.c
765

See "taskqueue_drain(queue, &task)"

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.

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?

This revision is now accepted and ready to land.May 28 2021, 4:15 PM
kib marked 5 inline comments as done.May 28 2021, 5:16 PM
kib added inline comments.
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 marked 2 inline comments as done.

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

This revision now requires review to proceed.May 28 2021, 5:17 PM
sys/kern/kern_thread.c
750

Why are you not using taskqueue_drain() here?

sys/kern/kern_thread.c
750

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

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?

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.

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

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

This revision is now accepted and ready to land.May 29 2021, 2:28 PM