<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:54:38 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-5801] client 2.5.2 - cgroups compatibility problem</title>
                <link>https://jira.whamcloud.com/browse/LU-5801</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;During internal tests it appeared that dd process get killed by OOM-Killer when it belongs to a cgroup with memory enforcement.&lt;/p&gt;

&lt;p&gt;In our scenario we use dd to write 10G file:&lt;br/&gt;
dd if=/dev/zero of=./testing bs=1M count=10000&lt;br/&gt;
Parent shell belongs to a cgroup with memory limit set to 1.5GB&lt;/p&gt;

&lt;p&gt;Our tests on local filesystems and GPFS  were fine - no oom killer invocations have been seen. Only Lustre operations tend to fail due to memory excess&lt;/p&gt;

&lt;p&gt;I&apos;m attaching oom details from dmesg&lt;/p&gt;

&lt;p&gt;&amp;#8211;&lt;br/&gt;
Lukasz Flis &lt;br/&gt;
ACC Cyfronet&lt;/p&gt;</description>
                <environment>Scientific Linux 6.5</environment>
        <key id="27288">LU-5801</key>
            <summary>client 2.5.2 - cgroups compatibility problem</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="lflis">Lukasz Flis</reporter>
                        <labels>
                    </labels>
                <created>Thu, 23 Oct 2014 22:25:06 +0000</created>
                <updated>Thu, 24 Nov 2022 00:07:21 +0000</updated>
                                            <version>Lustre 2.7.0</version>
                    <version>Lustre 2.5.2</version>
                                                        <due></due>
                            <votes>1</votes>
                                    <watches>11</watches>
                                                                            <comments>
                            <comment id="97424" author="adilger" created="Fri, 24 Oct 2014 17:24:18 +0000"  >&lt;p&gt;As yet, we haven&apos;t done any testing with Lustre and cgroups.  I suspect this relates to the way that clients determine the cache limits based on the total RAM and not on the memory available to the cgroup.  I suspect that this needs fixing in several places (max_dirty_mb, max_cached_mb, lu_cache limits, DLM pool limits, etc) to check the cgroup available memory instead of &lt;tt&gt;totalram_pages&lt;/tt&gt;.  That said, I don&apos;t know enough about cgroups yet to know what to check...&lt;/p&gt;</comment>
                            <comment id="97462" author="lflis" created="Fri, 24 Oct 2014 20:49:04 +0000"  >&lt;p&gt;I was looking for workaround and tried setting lustre.max_dirty_mb below the cgroup limit. Unfortunately no luck this time.&lt;/p&gt;</comment>
                            <comment id="99098" author="lflis" created="Thu, 13 Nov 2014 20:39:22 +0000"  >&lt;p&gt;Hello&lt;/p&gt;

&lt;p&gt;Since cgroups memory limiting  is quite important functionality for us I&apos;d like to ask if the fix is likely to appear in 2.5.x line?&lt;/p&gt;

&lt;p&gt;Best Regards&lt;br/&gt;
&amp;#8211;&lt;br/&gt;
Lukasz Flis&lt;/p&gt;</comment>
                            <comment id="99133" author="adilger" created="Fri, 14 Nov 2014 01:30:18 +0000"  >&lt;p&gt;All new features will appear in master before possibly being backported to a maintenance branch.  Since master is currently in feature freeze for 2.7.0 it is unlikely that this feature would be implemented in the next few months.&lt;/p&gt;</comment>
                            <comment id="118342" author="lflis" created="Fri, 12 Jun 2015 10:32:45 +0000"  >&lt;p&gt;Hello Andreas,&lt;/p&gt;

&lt;p&gt;Are there any news regarding the memory cgroup support in new Lustre client versions?&lt;/p&gt;
</comment>
                            <comment id="217708" author="twhitehead" created="Mon, 8 Jan 2018 18:53:40 +0000"  >&lt;p&gt;Just adding another voice here for this bug to get some TLC as we&apos;ve (Compute Canada) ran into it in a couple of cases with our users now.  Would be great if it could get addressed.&lt;/p&gt;

&lt;p&gt;Thanks!  -Tyson&lt;/p&gt;</comment>
                            <comment id="219248" author="pjones" created="Fri, 26 Jan 2018 13:37:08 +0000"  >&lt;p&gt;Has this issue been seen running on a current 2.10.x LTS release?&lt;/p&gt;</comment>
                            <comment id="219262" author="paf" created="Fri, 26 Jan 2018 15:52:21 +0000"  >&lt;p&gt;Peter,&lt;/p&gt;

&lt;p&gt;You can check with Andreas, but I&apos;m pretty confident the problem still exists.  It&apos;s both a design issue and a design question.  (I recall discussing it with Andreas in a JIRA at one point, but either my memory is bad or it was another JIRA.)  We may not want to solve the problem in the way the reporter requested, but we haven&apos;t changed things here yet either.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                                        </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="16208" name="cgroup-killer.log" size="20671" author="lflis" created="Thu, 23 Oct 2014 22:25:06 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzwzdr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>16267</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>