From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752872Ab2CPRjz (ORCPT ); Fri, 16 Mar 2012 13:39:55 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:33319 "EHLO e28smtp08.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512Ab2CPRjv (ORCPT ); Fri, 16 Mar 2012 13:39:51 -0400 From: "Aneesh Kumar K.V" To: linux-mm@kvack.org, mgorman@suse.de, kamezawa.hiroyu@jp.fujitsu.com, dhillf@gmail.com, aarcange@redhat.com, mhocko@suse.cz, akpm@linux-foundation.org, hannes@cmpxchg.org Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: [PATCH -V4 00/10] memcg: Add memcg extension to control HugeTLB allocation Date: Fri, 16 Mar 2012 23:09:20 +0530 Message-Id: <1331919570-2264-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.9 x-cbid: 12031617-2000-0000-0000-000006CC307F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, This patchset implements a memory controller extension to control HugeTLB allocations. The extension allows to limit the HugeTLB usage per control group and enforces the controller limit during page fault. Since HugeTLB doesn't support page reclaim, enforcing the limit at page fault time implies that, the application will get SIGBUS signal if it tries to access HugeTLB pages beyond its limit. This requires the application to know beforehand how much HugeTLB pages it would require for its use. The goal is to control how many HugeTLB pages a group of task can allocate. It can be looked at as an extension of the existing quota interface which limits the number of HugeTLB pages per hugetlbfs superblock. HPC job scheduler requires jobs to specify their resource requirements in the job file. Once their requirements can be met, job schedulers like (SLURM) will schedule the job. We need to make sure that the jobs won't consume more resources than requested. If they do we should either error out or kill the application. Changes from v3: * Address review feedback. * bug fix in cgroup removal related parent charging with use_hierarchy set Changes from V2: * Changed the implementation to limit the HugeTLB usage during page fault time. This simplifies the extension and keep it closer to memcg design. This also allows to support cgroup removal with less complexity. Only caveat is the application should ensure its HugeTLB usage doesn't cross the cgroup limit. Changes from V1: * Changed the implementation as a memcg extension. We still use the same logic to track the cgroup and range. Changes from RFC post: * Added support for HugeTLB cgroup hierarchy * Added support for task migration * Added documentation patch * Other bug fixes -aneesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Subject: [PATCH -V4 00/10] memcg: Add memcg extension to control HugeTLB allocation Date: Fri, 16 Mar 2012 23:09:20 +0530 Message-ID: <1331919570-2264-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> Return-path: Sender: owner-linux-mm@kvack.org List-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-mm@kvack.org, mgorman@suse.de, kamezawa.hiroyu@jp.fujitsu.com, dhillf@gmail.com, aarcange@redhat.com, mhocko@suse.cz, akpm@linux-foundation.org, hannes@cmpxchg.org Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Hi, This patchset implements a memory controller extension to control HugeTLB allocations. The extension allows to limit the HugeTLB usage per control group and enforces the controller limit during page fault. Since HugeTLB doesn't support page reclaim, enforcing the limit at page fault time implies that, the application will get SIGBUS signal if it tries to access HugeTLB pages beyond its limit. This requires the application to know beforehand how much HugeTLB pages it would require for its use. The goal is to control how many HugeTLB pages a group of task can allocate. It can be looked at as an extension of the existing quota interface which limits the number of HugeTLB pages per hugetlbfs superblock. HPC job scheduler requires jobs to specify their resource requirements in the job file. Once their requirements can be met, job schedulers like (SLURM) will schedule the job. We need to make sure that the jobs won't consume more resources than requested. If they do we should either error out or kill the application. Changes from v3: * Address review feedback. * bug fix in cgroup removal related parent charging with use_hierarchy set Changes from V2: * Changed the implementation to limit the HugeTLB usage during page fault time. This simplifies the extension and keep it closer to memcg design. This also allows to support cgroup removal with less complexity. Only caveat is the application should ensure its HugeTLB usage doesn't cross the cgroup limit. Changes from V1: * Changed the implementation as a memcg extension. We still use the same logic to track the cgroup and range. Changes from RFC post: * Added support for HugeTLB cgroup hierarchy * Added support for task migration * Added documentation patch * Other bug fixes -aneesh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org