Bug 103229

Summary:	LTC4129-CONFIG_X86_4G is on by default
Product:	Red Hat Enterprise Linux 3	Reporter:	IBM Bug Proxy <bugproxy>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	3.0	CC:	riel
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 18:58:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description IBM Bug Proxy 2003-08-27 22:08:14 UTC

The following has be reported by IBM LTC:  
CONFIG_X86_4G is on by default
Hardware Environment:
Any

Software Environment:
RHEL 3.0beta1

Additional Information:
Apparently, CONFIG_X86_4G is on by default in all kernels in RHEL 3.0.  This
breaks GPFS in a very bad way, because GPFS has userspace and kernel components
that communicate via a shared region in kernel memory area, and this options
makes kernel space inaccessible from userspace.  There's no workaround.  This
option is only needed for big-memory machines, and imposes a severe performance
penalty, and it's not clear why it's on by default on all kernels.Glen/Greg -
please submit this to Red Hat.  Thanks.

Comment 1 Arjan van de Ven 2003-08-27 22:16:30 UTC


*** This bug has been marked as a duplicate of 78616 ***

Comment 2 Arjan van de Ven 2003-08-27 22:17:45 UTC

also your statement is incorrect.
It shows that your binary only filesystem is incorrectly coded. Several other
(GPL) modules DO have shared kernel/userspace memory and work JUST FINE with
4G/4G split, but they are coded properly

Comment 3 IBM Bug Proxy 2003-08-28 15:58:34 UTC

------- Additional Comment #5 From Yuri L. Volobuev  2003-08-27 18:57 -------

In response to RH bugzilla comment:
Just for the record, the portion of GPFS code that sets up the shared memory
region is open-sourced (BSD license), so please stop bringing in "binary only"
as an issue.  Not every GPFS problem is automatically caused by its
non-opensourcenes. The real issue is the method for setting up a shared memory
region.  GPFS does it in an unusual way, for historical reasons.  Whether this
way is "incorrect" can be debated.  It's worked so far. 

Aside from the issue of GPFS breaking, one should be concerned about other
implications of this option, namely the stiff performance penalty of frequent
TLB flushes.  Given that the option is only applicable on machines with more
than 1GB of RAM, and the option help blurb itself states that machines with less
than 4GB of RAM will rarely see any benefit from this option.  So why enable it
by default in all kernels?  Wouldn't it make more sense to only enable it in a
specialty kernel?

Comment 4 Bob Johnson 2003-08-28 16:15:51 UTC

Config was on in B1 for broad testing of our 4G/4G split.
It is now only on in the hugemem kernel.

Comment 5 IBM Bug Proxy 2003-08-28 20:59:29 UTC

------ Additional Comments From khoa.com  2003-28-08 15:06 -------
Yuri - Please verify that the config_x86_4G option is not on by default
in beta2.  Please re-open this bug report if it is still on.  Thanks.

Comment 6 IBM Bug Proxy 2003-08-30 00:55:56 UTC

------ Additional Comments From volobuev.com  2003-29-08 19:33 -------
Verified that CONFIG_X86_4G is only on in hugemem kernel in beta2.  Issue 
closed.

Comment 7 Red Hat Bugzilla 2006-02-21 18:58:18 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.