[SERVER-56416] mongod --version returns with extraneous log line on M1 laptops Created: 27/Apr/21  Updated: 29/Oct/23  Resolved: 02/Sep/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.4.10, 5.0.4, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Louisa Berger Assignee: Matthew Saltz (Inactive)
Resolution: Fixed Votes: 1
Labels: neweng, servicearch-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Backport Requested:
v5.0, v4.4
Sprint: Service Arch 2021-09-06
Participants:
Story Points: 2

 Description   

While testing out a new M1 laptop for Cloud, I noticed that the output of mongod --version is different for MDB enterprise 4.4 binaries. Automation notices because we parse that output to determine the version details for a mongo binary.

On M1:

louisa.berger@M-C02F764NQ05N go_planner % /tmp/mms-automation/test/versions/mongodb-macos-x86_64-enterprise-4.4.5/bin/mongod --version
{"t":{"$date":"2021-04-16T15:31:12.455Z"},"s":"I",  "c":"CONTROL",  "id":23351,   "ctx":"main","msg":"{sysctlName} unavailable","attr":{"sysctlName":"machdep.cpu.extfeatures"}}
db version v4.4.5
Build Info: {
    "version": "4.4.5",
    "gitVersion": "ff5cb77101b052fa02da43b8538093486cf9b3f7",
    "modules": [
        "enterprise"
    ],
    "allocator": "system",
    "environment": {
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

Not on M1:

(default) louisamac:versions louisaberger$ mongodb-macos-x86_64-enterprise-4.4.5/bin/mongod --version
db version v4.4.5
Build Info: {
    "version": "4.4.5",
    "gitVersion": "ff5cb77101b052fa02da43b8538093486cf9b3f7",
    "modules": [
        "enterprise"
    ],
    "allocator": "system",
    "environment": {
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

Note – this is just enterprise, not community.

acm suggested I file a ticket here, and that we could remove that log line.



 Comments   
Comment by Githook User [ 29/Sep/21 ]

Author:

{'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}

Message: SERVER-56416 Remove non-portable cpuFeatures check from macOS

(cherry picked from commit 56c91fc80fe8224c5469c776e85b885cd0367dbb)
Branch: v5.0
https://github.com/mongodb/mongo/commit/8fa98eabf9d355972163783329167f242e6f5de5

Comment by Githook User [ 29/Sep/21 ]

Author:

{'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}

Message: SERVER-56416 Remove non-portable cpuFeatures check from macOS

(cherry picked from commit 56c91fc80fe8224c5469c776e85b885cd0367dbb)
Branch: v4.4
https://github.com/mongodb/mongo/commit/a58ba9f4fcb62d0805d1e05512525be320299b4d

Comment by Githook User [ 31/Aug/21 ]

Author:

{'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}

Message: SERVER-56416 Remove non-portable cpuFeatures check from macOS
Branch: master
https://github.com/mongodb/mongo/commit/56c91fc80fe8224c5469c776e85b885cd0367dbb

Comment by Matthew Saltz (Inactive) [ 30/Aug/21 ]

Thanks everyone for the feedback. I'll just go with the approach of removing the field on macOS then

Comment by Bruce Lucas (Inactive) [ 26/Aug/21 ]

As a weak justification for cpuFeatures, ISTR once or twice laboriously comparing CPU features strings between processors to see if we could explain performance differences due to CPU features. I don't recall whether that exercise proved useful.

Comment by Andrew Morrow (Inactive) [ 26/Aug/21 ]

milkie - Ah, that's right. I forgot about rosetta. But, perhaps there is a runtime check that could be made as well, or we could provide a mechanism to allow certain queries to fail silently. Again, anything other than simply dropping it wholesale is being quite conservative, because we really don't think that the cpuFeatures is particularly meaningful.

Comment by Eric Milkie [ 26/Aug/21 ]

I thought it was possible to simply run Intel binaries on M1's via Rosetta – so the preprocessor #ifdef technique wouldn't work for that.

Comment by Andrew Morrow (Inactive) [ 26/Aug/21 ]

The inclusion of the cpuFeatures is from the dawn of time in SERVER-4615. No particular context is provided for its inclusion, and I'm also unaware of any consumers. I expect it was added for macOS to maintain parity with the linux ProcessInfo. So I think it is fine to remove from macOS if we like. Alternatively, we could be conservative and #ifdef it out on macOS on ARM. I'm sure there is a relevant preprocessor widget we can inspect.

Comment by Matthew Saltz (Inactive) [ 25/Aug/21 ]

milkie That's a good point - I don't actually know what that information gets used for, if anything, so if you or acm have more context on that and think it's okay to just remove the "cpuFeatures" line, then that's definitely the easiest solution and I"m fine with that.

Comment by Eric Milkie [ 25/Aug/21 ]

I think that first issue comes from some Mac-specific code that was written back in 2012 and hasn't been touched since. The easiest solution here might be to just remove the fetching of that particular option for everyone.

Comment by Matthew Saltz (Inactive) [ 25/Aug/21 ]

It seems like there are a few issues here:

The quick fix to make this particular issue go away might be to make the TcmallocConfigurationDefaults initializer depend on the MongodOptions initializer so that it doesn't run before the version info is processed. We should probably also fix the first issue, though I feel like SDP may have more expertise in that area than service arch. I'll play with the initializer dependency graph to see if that works, though it definitely feels hacky.

Generated at Thu Feb 08 05:39:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.