Read Concern Majority when majority nodes are down
Using a read concern of &quot;majority&quot; does not cause the read operation to be submitted to multiple nodes.
When replication.enableMajorityReadConcern is true (default in MongoDB 3.6+) each node will note the most recent write operation that has been acknowledged by a majority of the voting nodes, and keep a snapshot of the data at that point in time.
A request using &quot;majority&quot; read concern instructs the mongod to read from that snapshot instead of the most recent write.
In your scenario, reads will continue normally with 3 nodes down.
In addition to keeping the snapshot at the latest majority commit, each node must also accept writes.  Keeping track of the not-yet-majority writes in addition to the majority snapshot requires some additional usage of cache.  If a cluster gets into a state where there is a primary and is able to accept writes, but is unable to replicate those writes to a majority of the voting nodes, this cache usage can increase to the point of causing system instability.
That can only occur when there is a voting member that does not contain data, i.e. an arbiter.
Since your scenario does not contain an arbiter, that cluster should not have the RCM-induced cache pressure issue.