Page MenuHomeFreeBSD

Exclude Giant from adaptive locking.
Needs ReviewPublic

Authored by hselasky on Jul 5 2021, 1:40 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 19, 3:10 AM
Unknown Object (File)
Sep 7 2025, 6:34 AM
Unknown Object (File)
Aug 17 2025, 1:35 AM
Unknown Object (File)
Jul 13 2025, 6:01 AM
Unknown Object (File)
Jun 22 2025, 6:08 PM
Unknown Object (File)
Apr 19 2025, 6:18 AM
Unknown Object (File)
Apr 4 2025, 4:06 PM
Unknown Object (File)
Apr 1 2025, 5:06 PM
Subscribers

Details

Reviewers
mjg
kib
markj
imp
Summary

Giant may be frequently locked over longer periods of time and is not fit
for adaptive mutex locking.

MFC after: 1 week
Sponsored by: NVIDIA Networking

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

hselasky created this revision.

I would say that's very unclear.

Can you point at the problematic Giant consumer? More to the point, is there a serious problem moving them off to a dedicated lock?

@mjg:

It is a problem at least when loading and unloading PCI drivers, and during boot.

The problem is that syscons has a timer to disable the blank screen, which is Giant protected. This single Giant locked callout ends up blocking all callouts on the particular CPU it is invoked.

Also when Giant is locked for a longer timer all consumers like USB enumeration threads start spinning for nothing!

--HPS

I think this should better be postponed a bit until we fix all other Giant consumers except newbus, assuming it is what causes the longest delays.