RHPAM Kogito Operator 7.x installation is failing with OOMKilled and CrashLoopBackOff

Sometimes RHPAM Kogito Operator 7.x installation gets stuck in the "installing" state. The reason behind this is rhpam-kogito-operator-controller-manager pod with default memory limits is being OOMKilled and is stuck in a CrashLoopBackOff.

oc get pods -n openshift-operators | grep rhpam
NAME                                                       READY   STATUS             RESTARTS          AGE
rhpam-kogito-operator-controller-manager-xxxxxxxx-xxxxx    1/2     CrashLoopBackOff   262 (4m14s ago)   24h

oc describe pod rhpam-kogito-operator-controller-manager-xxxxxxxx-xxxxx

[...]
State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Tue, 20 Dec 2022 19:13:48 +0530
      Finished:     Tue, 20 Dec 2022 19:14:16 +0530
    Ready:          False
    Restart Count:  262
[...]

The default memory limit (i.e., 200mi) that was set on the rhpam-kogito-operator-controller-manager pod was not sufficient. After increasing the memory limit, the pod came up running.

On checking the memory consumption of rhpam-kogito-operator-controller-manager pod after increasing the memory limit, I found that the memory consumption is more that the default limit:

oc adm top pod | grep rhpam
NAME                                                        CPU(cores)   MEMORY(bytes)
rhpam-kogito-operator-controller-manager-xxxxxxxxx-xxxxx    2m           250Mi   <-----

Increasing the default memory limit is as workaround for this issue and I am creating a KCS solution to address it.
https://access.redhat.com/solutions/6991378

I am creating this bug ticket to get your views on increasing the default memory limit to ensure successful operator installation. Please let me know if more information is needed.