cgroup: get right value when cgroup set max value

[hawkingrei]

Signed-off-by: Weizhen Wang wangweizhen@pingcap.com

What problem does this PR solve?

Issue Number: close #38664

Problem Summary:

What is changed and how it works?

in the old code, we cannot judge the container when it is in the docker compose.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)

test in the docker by @amyangfei

• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• amyangfei
• lance6716

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[hawkingrei]

/run-build

[wuhuizuo]

/run-all-tests

[lance6716]

Not have much certainty that 0::/ represent it's inside a container.

The entry for cgroup v2 is always in the format “0::$PATH”:

https://docs.kernel.org/admin-guide/cgroup-v2.html

After some searching 0::/ represent "root cgroup", but I'm not sure it means this process is inside a container

[wuhuizuo]

/run-all-tests

[lance6716]

in my PC

/hold

[amyangfei]

Not have much certainty that 0::/ represent it's inside a container.

The entry for cgroup v2 is always in the format “0::$PATH”:

https://docs.kernel.org/admin-guide/cgroup-v2.html

After some searching 0::/ represent "root cgroup", but I'm not sure it means this process is inside a container

It depends on the cgroup hierarchy, maybe it is better to check whether cgroup is enabled for the current process instead of checking whether it is running in a container.

[lance6716]

if cgroup is enabled, we use memory limit from cgroup, otherwise we use memory limit of physical machine

[hawkingrei]

@lance6716 fix the wrong handling when cgroup is set as the max value.

[hawkingrei]

/unhold

[hawkingrei]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: cb6c759

[hawkingrei]

/run-all-tests

[sre-bot]

TiDB MergeCI notify

🔴 Bad News! New failing [1] after this pr merged.
These new failed integration tests seem to be caused by the current PR, please try to fix these new failed integration tests, thanks!

CI Name	Result	Duration	Compare with Parent commit
idc-jenkins-ci-tidb/integration-common-test	🟥	1 min 54 sec	New failing
idc-jenkins-ci-tidb/integration-ddl-test	🔴 failed 1, success 5, total 6	30 min	Existing failure
idc-jenkins-ci/integration-cdc-test	🟢 all 38 tests passed	25 min	Existing passed
idc-jenkins-ci-tidb/common-test	🟢 all 11 tests passed	18 min	Existing passed
idc-jenkins-ci-tidb/tics-test	🟢 all 1 tests passed	7 min 3 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2	🟢 all 28 tests passed	6 min 2 sec	Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1	🟢 all 26 tests passed	4 min 34 sec	Existing passed
idc-jenkins-ci-tidb/mybatis-test	🟢 all 1 tests passed	3 min 54 sec	Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test	🟢 all 1 tests passed	2 min 51 sec	Existing passed
idc-jenkins-ci-tidb/plugin-test	🟢 build success, plugin test success	4min	Existing passed