public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Anton Blanchard <anton@samba.org>, Andrew Morton <akpm@osdl.org>,
	Stephen Smalley <sds@epoch.ncsc.mil>
Cc: Andi Kleen <ak@suse.de>,
	raybry@sgi.com, lse-tech@lists.sourceforge.net,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Martin J. Bligh" <mbligh@aracnet.com>
Subject: [PATCH] [0/6] HUGETLB memory commitment
Date: Thu, 25 Mar 2004 16:54:32 +0000	[thread overview]
Message-ID: <18429360.1080233672@42.150.104.212.access.eclipse.net.uk> (raw)

Here is the latest incarnation of my hugetlb patches.  Rediffed
against 2.6.5-rc2-bk4.  With the addition of
080-mem_acctdom_hugetlb_sysctl which generalises the sysctl 
support and uses it for hugetlb.

The overall problem is described below.  Feedback and testing
appreciated.

Cheers.

-apw


HUGETLB Overcommit Handling
---------------------------
When building mappings the kernel tracks committed but not yet
allocated pages against available memory and swap preventing memory
allocation problems later.  The introduction of hugetlb pages has
has significant ramifications for this accounting as the pages used
to back them are already removed from the available memory pool.
Currently mapping involving these pages are still accounted against
the small page pool leading to either over commitment of the normal
page pool, or incorrectly failed hugetlb allocations in the case
where hugetlb memory exceeds the remaining normal pool.  Also as
there is no commitment tracking on hugetlb pages it is not possible
to safely fault them on demand which is a problem for large segments
where the prefault and clear times are excessive.

This patch set attempts to addresses of these issues and provide a
platform for fixing the remainder.  Firstly, by removing the hugetlb
allocations from the normal page pool.  Secondly, by introducing a
general mechanism for accounting for multiple page pools.  Thirdly,
by implmenting and enforcing hugetlb commitments via these pools.

050-mem_acctdom_core:		core changes to create two accounting domains
055-mem_acctdom_arch:		architecture specific changes for above
060-mem_acctdom_commitments:	splits vm_committed into a per domain count
070-mem_acctdom_hugetlb: 	use vm_committed to track HUGETLB usage
075-mem_acctdom_hugetlb_arch:	architecture specific changes for above
080-mem_acctdom_hugetlb_sysctl: generalise sysctl parameters and add hugetlb

These first two patches introduce the concept of a split between
the default and hugetlb memory pools and stop the hugtlb pool
being accounted at all.  This is not as clean as I would like,
particularly the need to check against VM_AD_DEFAULT in a few places.

The third patch splits the vm_committed count into a per domain
count and exposes the domain in the interface.

The fourth and fifth patches convert hugetlb to use the vm_commitment
interfaces exposed above.

The sixth patch generalises the overcommit mode and rations to all
domains and adds support for controlling the hugetlb domain with it.

Below is a transcript of a test showing the commitments being
applied.  The test attempts to make 3 400x2MB page shared memory
segments, 850 pages are available.  The main things to note are
the commitment against the pages at shmget() time.  This is a
prerequisite for reliable accounting under fault driven page
instantiation.

    [root@kite apw]# ./tester
    kernel.shmmax = 2147483648
    kernel.shmall = 2147483648
    vm.nr_hugepages = 850
    == FIRST =    == before shmget =    HugePages_Total:   850
    HugePages_Free:    850
    Hugepagesize:     2048 kB
    HugeCommited_AS:        0 kB
    == before shmat =    HugePages_Total:   850
    HugePages_Free:    850
    Hugepagesize:     2048 kB
    HugeCommited_AS:   819200 kB
    test: shmat smpB200000
    == after shmat =    HugePages_Total:   850
    HugePages_Free:    450
    Hugepagesize:     2048 kB
    HugeCommited_AS:   819200 kB
    == SECOND =    == before shmget =    HugePages_Total:   850
    HugePages_Free:    450
    Hugepagesize:     2048 kB
    HugeCommited_AS:   819200 kB
    == before shmat =    HugePages_Total:   850
    HugePages_Free:    450
    Hugepagesize:     2048 kB
    HugeCommited_AS:  1638400 kB
    test: shmat smpB200000
    == after shmat =    HugePages_Total:   850
    HugePages_Free:     50
    Hugepagesize:     2048 kB
    HugeCommited_AS:  1638400 kB
    == THIRD =    == before shmget =    HugePages_Total:   850
    HugePages_Free:     50
    Hugepagesize:     2048 kB
    HugeCommited_AS:  1638400 kB
    test: shmget failed - errno\x12
    == before ipcrm -M 0xdead0000 =    HugePages_Total:   850
    HugePages_Free:     50
    Hugepagesize:     2048 kB
    HugeCommited_AS:  1638400 kB
    == before ipcrm -M 0xdead0001 =    HugePages_Total:   850
    HugePages_Free:    450
    Hugepagesize:     2048 kB
    HugeCommited_AS:   819200 kB
    == before ipcrm -M 0xdead0002 =    HugePages_Total:   850
    HugePages_Free:    850
    Hugepagesize:     2048 kB
    HugeCommited_AS:        0 kB
    ipcrm: invalid key (0xdead0002)
    == after =    HugePages_Total:   850
    HugePages_Free:    850
    Hugepagesize:     2048 kB
    HugeCommited_AS:        0 kB
    vm.nr_hugepages = 0


             reply	other threads:[~2004-03-25 16:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-25 16:54 Andy Whitcroft [this message]
2004-03-25 16:58 ` [PATCH] [1/6] HUGETLB memory commitment Andy Whitcroft
2004-03-25 16:59 ` [PATCH] [2/6] " Andy Whitcroft
2004-03-25 17:00 ` [PATCH] [3/6] " Andy Whitcroft
2004-03-25 17:01 ` [PATCH] [4/6] " Andy Whitcroft
2004-03-25 17:02 ` [PATCH] [5/6] " Andy Whitcroft
2004-03-25 17:03 ` [PATCH] [6/6] " Andy Whitcroft
2004-03-25 21:04 ` [PATCH] [0/6] " Andrew Morton
2004-03-25 23:27   ` Andy Whitcroft
2004-03-25 23:51     ` Andrew Morton
2004-03-25 23:59       ` Andy Whitcroft
2004-03-26  2:01         ` Andy Whitcroft
2004-03-26  0:18       ` Martin J. Bligh
2004-03-28 18:02     ` Ray Bryant
2004-03-28 19:10       ` Martin J. Bligh
2004-03-28 21:32         ` [Lse-tech] " Ray Bryant
2004-03-29 16:50           ` Martin J. Bligh
2004-03-29 12:30         ` Andy Whitcroft
2004-03-26  0:10 ` Keith Owens
2004-03-26  0:22   ` Andrew Morton
2004-03-26  3:41     ` [Lse-tech] " Suparna Bhattacharya
2004-03-26  3:39       ` Keith Owens
2004-03-26 11:45         ` Suparna Bhattacharya
2004-03-29 20:45 ` Chen, Kenneth W
2004-03-29 20:49 ` Chen, Kenneth W
2004-03-30 12:57   ` Andy Whitcroft
2004-03-30 20:04 ` Chen, Kenneth W
2004-03-30 21:48   ` Andy Whitcroft
2004-03-31  1:48     ` Andy Whitcroft
2004-03-31  8:51 ` Chen, Kenneth W
2004-03-31 16:20   ` Andy Whitcroft
2004-04-01 21:15   ` Andy Whitcroft
2004-04-01 22:50     ` Andy Whitcroft
2004-04-01 23:09 ` Chen, Kenneth W
2004-04-03  3:57   ` [PATCH] " Ray Bryant
2004-04-04  3:31     ` Chen, Kenneth W
2004-04-04 22:15       ` Ray Bryant
2004-04-05 15:26       ` [Lse-tech] " Ray Bryant
2004-04-05 17:01         ` Chen, Kenneth W
2004-04-05 18:22           ` Ray Bryant
2004-04-05 23:18         ` Chen, Kenneth W
2004-04-06  1:05           ` Ray Bryant
2004-04-06 16:14           ` Andy Whitcroft
2004-04-06 17:40         ` Chen, Kenneth W

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18429360.1080233672@42.150.104.212.access.eclipse.net.uk \
    --to=apw@shadowen.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=mbligh@aracnet.com \
    --cc=raybry@sgi.com \
    --cc=sds@epoch.ncsc.mil \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox