Spectrum Scale / ESS soft lockup issue

I need help on this requirements for the system using Power9 AC922 servers and ESS 3000 storages. The customer has faced soft lockup issues with their applications running on AC922 which Spectrum Scale client runs on as well. They are definitely trying to solve issues on their application, however in the meantime, those are very strict for use in production and we have been strongly requested to provide alternatives.

Problems:
Two or more application processes on multiple nodes in a Scale cluster open a single identical file with RO (Read Only). Once soft lockup happened, other processes cause inaccessible to the Scale cluster until the locked node is expelled from the cluster after 'failureDetectionTime' exceeds. The customer is NOT acceptable for waiting for its recovery.

Reasons:
Metanode which is responsible for the RO file to manage i-node information hangs up, succeeding processes which want to ask its status to metanode and/or to request revoking tokens must be waited.

Alternative Ideas:
1.All applications do not modify any files. If the customer would not mind maintaining atime in metadata, I think there should be nobody who contaminates metadata information. Thus any locking mechanism would not be required.
We can specify 'noatime' option in mmchfs, and also can set '-i yes' in mmchattr to notify Scale of the Read Only.

Using the latest version of Spectrum Scale, the above scenario does not work, and we see still waiting for expelling. Thus some internal code enhancement would be required.

2. CPU cores binding for user's applications would be isolated from others which are responsible for Scale processes and other kernel processes. I just think we may use 'tuna', 'taskset' or 'isolcpus' to achieve the goal, but we do not have any technical sureness on it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/index