Page MenuHomeFreeBSD

vm: Remove kernel stack swapping support, part 2
ClosedPublic

Authored by markj on Jul 24 2024, 9:38 PM.
Tags
None
Referenced Files
F106227310: D46113.diff
Fri, Dec 27, 12:59 PM
Unknown Object (File)
Wed, Dec 11, 3:50 AM
Unknown Object (File)
Nov 25 2024, 4:52 AM
Unknown Object (File)
Nov 18 2024, 2:04 PM
Unknown Object (File)
Nov 13 2024, 11:09 PM
Unknown Object (File)
Nov 12 2024, 8:43 PM
Unknown Object (File)
Oct 21 2024, 8:21 AM
Unknown Object (File)
Oct 19 2024, 1:16 PM
Subscribers

Details

Summary

After mi_startup() finishes, thread0 becomes the "swapper", whose
responsibility is to swap threads back in on demand. Now that threads
can't be swapped out, there is no use for this thread. Just call
sched_throw() to exit.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 58811
Build 55698: arc lint + arc unit

Event Timeline

imp added inline comments.
sys/vm/vm_glue.c
840

Do we need this at all?

This revision is now accepted and ready to land.Jul 24 2024, 9:46 PM
sys/vm/vm_glue.c
840

No, but fixing up its callers will be a patch of its own. I didn't go that far yet.

Does this mean that thread0 is no longer functional? If yes, can we re-purpose it for something/anything instead of throwing?

In D46113#1051278, @kib wrote:

Does this mean that thread0 is no longer functional? If yes, can we re-purpose it for something/anything instead of throwing?

Right. Do you have any suggestions there? Hmm, after these changes there is still the vm_daemon(), to handle RACCT_RSS and RLIMIT_RSS. That is probably a good candidate.

In D46113#1051278, @kib wrote:

Does this mean that thread0 is no longer functional? If yes, can we re-purpose it for something/anything instead of throwing?

Right. Do you have any suggestions there? Hmm, after these changes there is still the vm_daemon(), to handle RACCT_RSS and RLIMIT_RSS. That is probably a good candidate.

This is only for RACCT I think. In the worst case I suggest to just park the thread by blocking it, or doing non-interruptible sleep on local var address.

markj added inline comments.
sys/vm/vm_glue.c
840

This is now done in parts 9 and 10.

Use tsleep() to park the thread in mi_startup().

This revision now requires review to proceed.Jul 25 2024, 2:09 PM
sys/kern/init_main.c
341

I wouldn't be surprised to find that this results in last being placed on the stack instead of a register. Could __builtin_frame_address(0) be used instead?

markj marked an inline comment as done.

Apply alc's suggestion.

This revision is now accepted and ready to land.Jul 25 2024, 10:52 PM
kib added inline comments.
sys/kern/init_main.c
341

There is pause() with the dedicated pause_wchan. Might be loop around pause()?

sys/kern/init_main.c
341

With pause(), we have to provide some arbitrary timeout, and a callout will be scheduled, so I slightly prefer the tsleep() call. I don't feel strongly about it and can change it if you prefer.

sys/kern/init_main.c
341

We can use pause_wchan at least. But either is fine.