Page MenuHomeFreeBSD

Add a dev.foo.N.%domain sysctl and bus_get_domain() wrapper.
ClosedPublic

Authored by jhb on Oct 9 2014, 6:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 25 2024, 10:46 PM
Unknown Object (File)
Mar 2 2024, 4:48 PM
Unknown Object (File)
Feb 7 2024, 6:10 PM
Unknown Object (File)
Jan 31 2024, 3:46 AM
Unknown Object (File)
Dec 19 2023, 10:43 PM
Unknown Object (File)
Dec 16 2023, 9:22 AM
Unknown Object (File)
Dec 10 2023, 11:13 PM
Unknown Object (File)
Oct 18 2023, 4:44 PM
Subscribers
None

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

jhb retitled this revision from to Add a dev.foo.N.%domain sysctl and bus_get_domain() wrapper..
jhb updated this object.
jhb edited the test plan for this revision. (Show Details)
jhb added a reviewer: adrian.

I've tested this on 8.x already with your other changes backported. Have not yet built a HEAD kernel with this applied. It's also at github/bsdjhb/freebsd/domain_sysctl

adrian edited edge metadata.

Yup. I was just compile testing my version of this. Go ahead!

This revision is now accepted and ready to land.Oct 9 2014, 6:51 PM

Konstantin, adding you to see what you think. I'm not sure exactly yet what we will end up with in HEAD as the final solution, but this data is useful for sysadmins at my current work in practice.

This has the same issue I reported when the bus_get_domain() was discussed; returning a vm domain may carry no sense. That said, now the thing becomes exposed to usermode and starts being part of the ABI.

I just realized that BUS_GET_DOMAIN commit mis-handled the DMARs. As I understand the wiring of calls, it results in ENOENT/no domain for them. I should fix this.

Do you have an alternate suggestion? I'm fine with marking bus_get_domain() as "XXX experimental, may be removed", etc. However, we need something here.

In D930#10, @jhb wrote:

Do you have an alternate suggestion? I'm fine with marking bus_get_domain() as "XXX experimental, may be removed", etc. However, we need something here.

Call it firmware_domain or proximity_domain ?

In D930#11, @kostikbel wrote:
In D930#10, @jhb wrote:

Do you have an alternate suggestion? I'm fine with marking bus_get_domain() as "XXX experimental, may be removed", etc. However, we need something here.

Call it firmware_domain or proximity_domain ?

Should we rename PCPU_GET(domain) as well then? (These are inherently the same thing in ACPI/x86 which is the only model we currently have to test/build in/design for. I'm a bit hesitant to add abstractions that only exist in hardware FreeBSD will never run on)

In D930#12, @jhb wrote:

Should we rename PCPU_GET(domain) as well then? (These are inherently the same thing in ACPI/x86 which is the only model we currently have to test/build in/design for. I'm a bit hesitant to add abstractions that only exist in hardware FreeBSD will never run on)

In-kernel names are somewhat easier, since there is no ABI-stability cost on changing them.

I do not mean non-x86 hardware when I am talking about vm domains not being same as bios/proximity domains. My concern are (not yet committed, but already used) patches which split bios vm domains into smaller chunks, in particular, to get sharding on page queue locks.

In D930#13, @kostikbel wrote:

In-kernel names are somewhat easier, since there is no ABI-stability cost on changing them.

Ok. If you want I can just leave out the sysctl for now. I have other more proximate uses for 'bus_get_domain' in HEAD.

I do not mean non-x86 hardware when I am talking about vm domains not being same as bios/proximity domains. My concern are (not yet committed, but already used) patches which split bios vm domains into smaller chunks, in particular, to get sharding on page queue locks.

As I said before, just call those shards something else besides "domain". "domain" has a well-known context in terms of computer memory: NUMA domains. It would be confusing to overload the "domain" term in the VM system to mean anything else.

In D930#14, @jhb wrote:
In D930#13, @kostikbel wrote:

In-kernel names are somewhat easier, since there is no ABI-stability cost on changing them.

Ok. If you want I can just leave out the sysctl for now. I have other more proximate uses for 'bus_get_domain' in HEAD.

Well, no. Commit it.

I do not mean non-x86 hardware when I am talking about vm domains not being same as bios/proximity domains. My concern are (not yet committed, but already used) patches which split bios vm domains into smaller chunks, in particular, to get sharding on page queue locks.

As I said before, just call those shards something else besides "domain". "domain" has a well-known context in terms of computer memory: NUMA domains. It would be confusing to overload the "domain" term in the VM system to mean anything else.

They are already called vm_domain. See vm/vm_page.h. I will rename them when the patches are to be revived.

kib edited edge metadata.
jhb edited edge metadata.

Update comment.

This revision now requires review to proceed.Nov 24 2014, 7:46 PM
jhb updated this revision to Diff 2537.

Closed by commit rS274976 (authored by @jhb).