On Mon, 2 Dec 2024 10:47:01 GMT, Severin Gehwolf wrote:
> And after the patch this would become this, right?
>
> ```
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> /sys/fs/cgroup/cpu,cpuacct/
> ```
It depends on whether it was a subgroup in th
On Sun, 1 Dec 2024 12:48:40 GMT, Sergey Chernyshev
wrote:
> In the Cloudflare case (cg v1 before patch), the path
> `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`
> will be adjusted as follows:
I assume that's the adjustment logic (pre-patch)
On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf wrote:
> In the cloudflare case we'd end up with a subsystem path of
> `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`.
> Since the cgroup_path != _root we trigger path adjustment increasing the
On Fri, 29 Nov 2024 14:47:13 GMT, Sergey Chernyshev
wrote:
> > Right. I'm still not convinced this extra reduction buys us much. The
> > adjust controller logic will handle it if kept as is in the Metrics version.
>
> The adjust controller logic won't handle it, because it reduces the path fro
On Wed, 27 Nov 2024 11:07:18 GMT, Severin Gehwolf wrote:
> Right. I'm still not convinced this extra reduction buys us much. The adjust
> controller logic will handle it if kept as is in the Metrics version.
The adjust controller logic won't handle it, because it reduces the path from
child to
On Wed, 27 Nov 2024 10:56:57 GMT, Sergey Chernyshev
wrote:
>>> Version specific code can be had in `set_subsystem_path()` of the
>>> corresponding impl (like an earlier version of your patch). `lowest_limit`
>>> and `limit_cg_path` fixes are version agnostic and can and should be fixed
>>> in
On Wed, 27 Nov 2024 09:08:30 GMT, Sergey Chernyshev
wrote:
> Done. Please see the updated PR.
The metrics part still needs the update - in the cgroup version specific
`setPath()`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860451322
On Mon, 25 Nov 2024 09:40:03 GMT, Severin Gehwolf wrote:
> Version specific code can be had in `set_subsystem_path()` of the
> corresponding impl (like an earlier version of your patch). `lowest_limit`
> and `limit_cg_path` fixes are version agnostic and can and should be fixed in
> `CgroupUti
On Sat, 23 Nov 2024 10:28:42 GMT, Sergey Chernyshev
wrote:
>>> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
>>> when path adjustment is deemed needed. So I'm not clear why it's needed for
>>> cg v2
>>
>> It looks like there's no way to see at this point, if we ar
On Sat, 23 Nov 2024 00:06:26 GMT, Sergey Chernyshev
wrote:
> It looks like there's no way to see at this point, if we are in cgroup v1 or
> v2 - if I am not mistaken.
On the other hand, a type parameter can be added to
`CgroupUtil::adjust_controller()`. Would you recommend doing so?
On Fri, 22 Nov 2024 16:48:04 GMT, Severin Gehwolf wrote:
> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
> when path adjustment is deemed needed. So I'm not clear why it's needed for
> cg v2
It looks like there's no way to see at this point, if we are in cgroup v1
On Fri, 22 Nov 2024 13:00:14 GMT, Sergey Chernyshev
wrote:
>>> Here, `limit` at line 64 is not stored as a possible lowest limit, so if
>>> the inner group has lower limit than the outer group, it won't be detected
>>> (cg v2 is affected too).
>>
>> Good spot! How about this to fix it?
>>
>>
On Fri, 22 Nov 2024 10:54:34 GMT, Severin Gehwolf wrote:
> Good spot! How about this to fix it?
>
> ```
> jlong limit = mem->read_memory_limit_in_bytes(phys_mem);
> jlong lowest_limit = limit < 0 ? phys_mem: limit;
> ```
Make sense to me.
> I'm worried about the added complexity. 1.) Is this
On Fri, 22 Nov 2024 09:54:39 GMT, Sergey Chernyshev
wrote:
> Here, `limit` at line 64 is not stored as a possible lowest limit, so if the
> inner group has lower limit than the outer group, it won't be detected (cg v2
> is affected too).
Good spot! How about this to fix it?
jlong limit = me
On Tue, 12 Nov 2024 23:29:47 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 46:
>>
>>> 44: }
>>> 45:
>>> 46: public void setPath(String cgroupPath) {
>>
>> This should behave the same as Hotspot and
On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf wrote:
>> Sergey Chernyshev has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>>
On Tue, 12 Nov 2024 14:59:41 GMT, Sergey Chernyshev
wrote:
> > The JBS issue doesn't mention `NullPointerException`. It would be good to
> > list the observed NPE issue.
>
> Example for NPE:
>
> ```
> public class Test {
> public static void main(String[] args) {
> java.lang.manag
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Tue, 12 Nov 2024 19:09:54 GMT, Sergey Chernyshev
wrote:
> > Edit: Yet, cg v2 will get into trouble since there, for example on rootless
> > podman on cg v2 you'd end up with this instead:
> > ```
> > [0.008s][trace][os,container] OSContainer::init: Initializing Container
> > Support
> > [0.
On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf wrote:
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
Example for NPE:
public class Test {
public static void main(String[] args) {
java.lang.management.ManagementFactory.
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Mon, 11 Nov 2024 18:28:11 GMT, Sergey Chernyshev
wrote:
> > So on cg v1 you start out and end with a `subsystem_path() == null` and on
> > cg v2 you start out and end with a `subsystem_path() ==
> > /../../../../../../test`. In both cases the memory limit of 400m won't be
> > detected.
>
On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf wrote:
> So on cg v1 you start out and end with a `subsystem_path() == null` and on cg
> v2 you start out and end with a `subsystem_path() ==
> /../../../../../../test`. In both cases the memory limit of 400m won't be
> detected.
Only when doc
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Mon, 11 Nov 2024 10:06:11 GMT, Severin Gehwolf wrote:
> > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
>
> The JBS issue doesn't mention `NullPointerException`. It would be good to
> list the observed NPE issue.
I also wonder, then, if the issue is NPE if
[JD
On Fri, 8 Nov 2024 16:11:37 GMT, Sergey Chernyshev
wrote:
> I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
The JBS issue doesn't mention `NullPointerException`. It would be good to list
the observed NPE issue.
-
PR Comment: https://git.openjdk.org/jdk
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> system
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
30 matches
Mail list logo
