Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Tue, Aug 06, 2013 at 07:22:02AM +0530, Aneesh Kumar K.V wrote: > Naoya Horiguchi writes: > >> > >> Considering that we have architectures that won't support migrating > >> explicit hugepages with this patch series, is it ok to use > >> GFP_HIGHUSER_MOVABLE for hugepage allocation ? > > > >

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi writes: >> >> Considering that we have architectures that won't support migrating >> explicit hugepages with this patch series, is it ok to use >> GFP_HIGHUSER_MOVABLE for hugepage allocation ? > > Originally this parameter was introduced to make hugepage pool on >

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Considering that we have architectures that won't support migrating explicit hugepages with this patch series, is it ok to use GFP_HIGHUSER_MOVABLE for hugepage allocation ? Originally this parameter was introduced to make hugepage pool on

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Tue, Aug 06, 2013 at 07:22:02AM +0530, Aneesh Kumar K.V wrote: Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Considering that we have architectures that won't support migrating explicit hugepages with this patch series, is it ok to use GFP_HIGHUSER_MOVABLE for hugepage allocation

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Thu, Aug 01, 2013 at 11:29:39AM +0530, Aneesh Kumar K.V wrote: > Naoya Horiguchi writes: > > > On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: > >> Naoya Horiguchi writes: > >> > >> > Now hugepages are definitely movable. So allocating hugepages from > >> > ZONE_MOVABLE is

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi writes: > On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: >> Naoya Horiguchi writes: >> >> > Now hugepages are definitely movable. So allocating hugepages from >> > ZONE_MOVABLE is natural and we have no reason to keep this parameter. >> > In order to allow

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Thu, Aug 01, 2013 at 11:29:39AM +0530, Aneesh Kumar K.V wrote: Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Now hugepages are definitely movable. So allocating

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: > Naoya Horiguchi writes: > > > Now hugepages are definitely movable. So allocating hugepages from > > ZONE_MOVABLE is natural and we have no reason to keep this parameter. > > In order to allow userspace to prepare for the

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

On Wed, Jul 31, 2013 at 12:02:30AM +0530, Aneesh Kumar K.V wrote: Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi writes: > Now hugepages are definitely movable. So allocating hugepages from > ZONE_MOVABLE is natural and we have no reason to keep this parameter. > In order to allow userspace to prepare for the removal, let's leave > this sysctl handler as noop for a while. I guess you still

Re: [PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Naoya Horiguchi n-horigu...@ah.jp.nec.com writes: Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to prepare for the removal, let's leave this sysctl handler as noop for a

[PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to prepare for the removal, let's leave this sysctl handler as noop for a while. ChangeLog v3: - use WARN_ON_ONCE ChangeLog v2: -

[PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to prepare for the removal, let's leave this sysctl handler as noop for a while. ChangeLog v3: - use WARN_ON_ONCE ChangeLog v2: -

[PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to prepare for the removal, let's leave this sysctl handler as noop for a while. ChangeLog v3: - use WARN_ON_ONCE ChangeLog v2: -

[PATCH 8/8] prepare to remove /proc/sys/vm/hugepages_treat_as_movable

Now hugepages are definitely movable. So allocating hugepages from ZONE_MOVABLE is natural and we have no reason to keep this parameter. In order to allow userspace to prepare for the removal, let's leave this sysctl handler as noop for a while. ChangeLog v3: - use WARN_ON_ONCE ChangeLog v2: -