Bug 103229 - LTC4129-CONFIG_X86_4G is on by default
LTC4129-CONFIG_X86_4G is on by default
Status: CLOSED DUPLICATE of bug 78616
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2003-08-27 18:08 EDT by IBM Bug Proxy
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:58:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2003-08-27 18:08:14 EDT
The following has be reported by IBM LTC:  
CONFIG_X86_4G is on by default
Hardware Environment:

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 18:16:30 EDT

*** This bug has been marked as a duplicate of 78616 ***
Comment 2 Arjan van de Ven 2003-08-27 18:17:45 EDT
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 11:58:34 EDT
------- 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 12:15:51 EDT
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 16:59:29 EDT
------ Additional Comments From khoa@us.ibm.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-29 20:55:56 EDT
------ Additional Comments From volobuev@us.ibm.com  2003-29-08 19:33 -------
Verified that CONFIG_X86_4G is only on in hugemem kernel in beta2.  Issue 
Comment 7 Red Hat Bugzilla 2006-02-21 13:58:18 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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