862803 – UV: numad fails on SGI - libcgroup issue

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 862803 - UV: numad fails on SGI - libcgroup issue

Summary: UV: numad fails on SGI - libcgroup issue

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	libcgroup
Sub Component:
Version:	6.4
Hardware:	x86_64
OS:	Linux
Priority:	medium
Severity:	high
Target Milestone:	rc
Target Release:	6.5
Assignee:	Jan Chaloupka
QA Contact:	Mike Gahagan
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	961026 996235 1056239 1075802 1164899
TreeView+	depends on / blocked

Reported:	2012-10-03 15:12 UTC by George Beshers
Modified:	2018-11-29 20:24 UTC (History)
CC List:	9 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2015-06-24 06:55:11 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Knowledge Base (Solution)	195603	0	None	None	None	2012-10-03 18:17:57 UTC

Description George Beshers 2012-10-03 15:12:16 UTC

Description of problem:
I am working on case 00696618.

The customer attempted to run "numad" on an SGI uv100 machine, but it failed because /cgroup/cpuset/cpuset.cpus doesn't exist.

With a default configuration on standard hardware, that file exists.

I notice that there are several cpuset and numa packages installed that are not from Red Hat, but from SGI.  For example:

cpuset-utils-2.0-sgi706r1.rhel6.x86_64                      Thu 09 Aug 2012 01:55:26 PM CEST
kmod-numatools-2.0-sgi706r3.rhel6.x86_64                    Mon 20 Aug 2012 05:52:33 PM CEST
libcpuset-1.0-sgi706r1.rhel6.x86_64                         Thu 09 Aug 2012 01:45:29 PM CEST
libnuma-3.0sgi-sgi706r1.rhel6.x86_64                        Thu 09 Aug 2012 01:55:35 PM CEST
numatools-2.0-sgi706r8.rhel6.x86_64                         Mon 20 Aug 2012 06:07:31 PM CEST

There are numerous other SGI packages, but it is not obvious to me what effects they have on cgroups, but they might be effecting the layout of /cgroup, such that it doesn't have /cgroup/cpuset/cpuset.cpus.


numad is currently in tech preview, but we probably want to fix the issue.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 George Beshers 2012-10-03 15:18:11 UTC

/etc/init.d/cgconfig is failing to start because the default config, which
lives in /etc/cgconfig.conf, tries to mount --among other controllers-- the
cgroup memory controller, but because we boot UV with cgroup_disable=memory,
the mount fails (more accurately cgconfigparser -l /etc/cgconfig.conf fails)
and the cgconfig service is designed such as you get either everything
or nothing.

As a test, I moved the original /etc/cgconfig.conf to /etc/cgconfig.conf.orig,
removed the memory = /cgroup/memory; line from /etc/cgconfig.conf, and now
things are working as expected i.e. you get all cgroup controllers aside from
the memory one.

There is a problem with scalability without "cgroup_disabled=memory".
This may not be an issue for a UV100 system.

Also, I have not tested this recently so it is worth checking
for Rhel7.

Comment 3 George Beshers 2012-10-03 15:37:42 UTC

Note: they will need to edit /etc/sysconfig/uvconfig to avoid
it editing /boot/efi/efi/redhat/grub.conf.

Comment 4 RHEL Program Management 2012-12-14 07:00:25 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 Peter Schiffer 2013-08-13 17:22:17 UTC

George,

so, what would be the ideal solution for this? Just skip the controllers defined in /etc/cgconfig.conf file which failed to mount?

Thanks,

peter

Comment 6 RHEL Program Management 2013-10-14 04:45:16 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 7 Jan Chaloupka 2014-02-25 12:33:47 UTC

Is there any progress in solving this issue? Ping George Beshers. Peter Schiffer, what is the latest information about it?

Comment 8 Peter Schiffer 2014-02-25 16:26:28 UTC

I've never get reply to my question from comment 5, so there's not much on my side.

peter

Comment 10 Jan Chaloupka 2014-03-05 13:45:03 UTC

Skipping not mounted controllers/subsystems is the same as not having them in cgconfig.conf. Just need to know which ones to skip. But if this is just the memory, is there any problem with commenting/removing the line with memory = /cgroup/memory in /etc/cgconfig.conf?

Comment 11 Jan Chaloupka 2014-08-05 07:09:52 UTC

ping

Comment 13 George Beshers 2015-06-24 00:32:26 UTC

This is no longer a problem.

This BZ should be closed.

Comment 14 Jan Chaloupka 2015-06-24 06:55:11 UTC

Thank you George for letting us know.

Kind Regards

Jan

Note You need to log in before you can comment on or make changes to this bug.