| Message ID | 20190402133415.21983-1-osalvador@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm/hugetlb: Get rid of NODEMASK_ALLOC | expand |
On 4/2/19 6:34 AM, Oscar Salvador wrote: > NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by ^ > first determining whether it should be allocated in the stack or dinamically ^ > depending on NODES_SHIFT. > Right now, it goes the dynamic path whenever the nodemask_t is above 32 > bytes. > > Although we could bump it to a reasonable value, the largest a nodemask_t > can get is 128 bytes, so since __nr_hugepages_store_common is called from > a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. ^ In addition, the possible call stacks after this routine are not too deep. Worst case is high order page allocation. > > This reduces some code churn and complexity. > > Signed-off-by: Oscar Salvador <osalvador@suse.de> Not a huge deal, but a few typos in the commit message. Thanks for the clean up. Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
On Tue, 2 Apr 2019 15:34:15 +0200 Oscar Salvador <osalvador@suse.de> wrote: > NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by > first determining whether it should be allocated in the stack or dinamically > depending on NODES_SHIFT. > Right now, it goes the dynamic path whenever the nodemask_t is above 32 > bytes. > > Although we could bump it to a reasonable value, the largest a nodemask_t > can get is 128 bytes, so since __nr_hugepages_store_common is called from > a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. > > This reduces some code churn and complexity. It took a bit of sleuthing to figure out that this patch applies to Mike's "hugetlbfs: fix potential over/underflow setting node specific nr_hugepages". Should they be folded together? I'm thinking not. (Also, should "hugetlbfs: fix potential over/underflow setting node specific nr_hugepages" have been -stableified? I also think not, but I bet it happens anyway).
On 4/2/19 1:01 PM, Andrew Morton wrote: > On Tue, 2 Apr 2019 15:34:15 +0200 Oscar Salvador <osalvador@suse.de> wrote: > >> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by >> first determining whether it should be allocated in the stack or dinamically >> depending on NODES_SHIFT. >> Right now, it goes the dynamic path whenever the nodemask_t is above 32 >> bytes. >> >> Although we could bump it to a reasonable value, the largest a nodemask_t >> can get is 128 bytes, so since __nr_hugepages_store_common is called from >> a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. >> >> This reduces some code churn and complexity. > > It took a bit of sleuthing to figure out that this patch applies to > Mike's "hugetlbfs: fix potential over/underflow setting node specific > nr_hugepages". Should they be folded together? I'm thinking not. No need to fold. They are separate issues and that over/underflow patch may already be doing too many things. > (Also, should "hugetlbfs: fix potential over/underflow setting node > specific nr_hugepages" have been -stableified? I also think not, but I > bet it happens anyway). I don't see a great reason for sending to stable. IIRC, nobody actually hit this issue: it was found through code inspection.
On Tue, 2019-04-02 at 13:01 -0700, Andrew Morton wrote: > It took a bit of sleuthing to figure out that this patch applies to > Mike's "hugetlbfs: fix potential over/underflow setting node specific > nr_hugepages". Should they be folded together? I'm thinking not. Sorry Andrew, I should have mentioned that this patch was based on Mike's "hugetlb fix potential over/underflow" patch. Given said that, I would keep the two patches separated, as that one is a fix, and this one is a cleanup. > (Also, should "hugetlbfs: fix potential over/underflow setting node > specific nr_hugepages" have been -stableified? I also think not, but > I > bet it happens anyway). I am not sure of the consequences in older branches, but if it is not too much of a hassle, it might be worth? Mike might know better here.
On Tue, Apr 02, 2019 at 03:34:15PM +0200, Oscar Salvador wrote: > NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by > first determining whether it should be allocated in the stack or dinamically > depending on NODES_SHIFT. > Right now, it goes the dynamic path whenever the nodemask_t is above 32 > bytes. > > Although we could bump it to a reasonable value, the largest a nodemask_t > can get is 128 bytes, so since __nr_hugepages_store_common is called from > a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. > > This reduces some code churn and complexity. > > Signed-off-by: Oscar Salvador <osalvador@suse.de> nice cleanup. Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
On 04/02/19 at 03:34pm, Oscar Salvador wrote: > NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by ~ and > first determining whether it should be allocated in the stack or dinamically dynamically^^ > depending on NODES_SHIFT. > Right now, it goes the dynamic path whenever the nodemask_t is above 32 > bytes. > > Although we could bump it to a reasonable value, the largest a nodemask_t > can get is 128 bytes, so since __nr_hugepages_store_common is called from > a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. > > This reduces some code churn and complexity. > > Signed-off-by: Oscar Salvador <osalvador@suse.de> > --- > mm/hugetlb.c | 36 +++++++++++------------------------- > 1 file changed, 11 insertions(+), 25 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index f79ae4e42159..9cb2f91af897 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, > unsigned long count, size_t len) > { > int err; > - NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY); > + nodemask_t nodes_allowed, *n_mask; > > - if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) { > - err = -EINVAL; > - goto out; > - } > + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) > + return -EINVAL; > > if (nid == NUMA_NO_NODE) { > /* > * global hstate attribute > */ > if (!(obey_mempolicy && > - init_nodemask_of_mempolicy(nodes_allowed))) { > - NODEMASK_FREE(nodes_allowed); > - nodes_allowed = &node_states[N_MEMORY]; > - } > - } else if (nodes_allowed) { > + init_nodemask_of_mempolicy(&nodes_allowed))) > + n_mask = &node_states[N_MEMORY]; > + else > + n_mask = &nodes_allowed; > + } else { > /* > * Node specific request. count adjustment happens in > * set_max_huge_pages() after acquiring hugetlb_lock. > */ > - init_nodemask_of_node(nodes_allowed, nid); > - } else { > - /* > - * Node specific request, but we could not allocate the few > - * words required for a node mask. We are unlikely to hit > - * this condition. Since we can not pass down the appropriate > - * node mask, just return ENOMEM. > - */ > - err = -ENOMEM; > - goto out; > + init_nodemask_of_node(&nodes_allowed, nid); > + n_mask = &nodes_allowed; > } > > - err = set_max_huge_pages(h, count, nid, nodes_allowed); > - > -out: > - if (nodes_allowed != &node_states[N_MEMORY]) > - NODEMASK_FREE(nodes_allowed); > + err = set_max_huge_pages(h, count, nid, n_mask); > > return err ? err : len; > } > -- > 2.13.7 >
diff --git a/mm/hugetlb.c b/mm/hugetlb.c index f79ae4e42159..9cb2f91af897 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2447,44 +2447,30 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, unsigned long count, size_t len) { int err; - NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY); + nodemask_t nodes_allowed, *n_mask; - if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) { - err = -EINVAL; - goto out; - } + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) + return -EINVAL; if (nid == NUMA_NO_NODE) { /* * global hstate attribute */ if (!(obey_mempolicy && - init_nodemask_of_mempolicy(nodes_allowed))) { - NODEMASK_FREE(nodes_allowed); - nodes_allowed = &node_states[N_MEMORY]; - } - } else if (nodes_allowed) { + init_nodemask_of_mempolicy(&nodes_allowed))) + n_mask = &node_states[N_MEMORY]; + else + n_mask = &nodes_allowed; + } else { /* * Node specific request. count adjustment happens in * set_max_huge_pages() after acquiring hugetlb_lock. */ - init_nodemask_of_node(nodes_allowed, nid); - } else { - /* - * Node specific request, but we could not allocate the few - * words required for a node mask. We are unlikely to hit - * this condition. Since we can not pass down the appropriate - * node mask, just return ENOMEM. - */ - err = -ENOMEM; - goto out; + init_nodemask_of_node(&nodes_allowed, nid); + n_mask = &nodes_allowed; } - err = set_max_huge_pages(h, count, nid, nodes_allowed); - -out: - if (nodes_allowed != &node_states[N_MEMORY]) - NODEMASK_FREE(nodes_allowed); + err = set_max_huge_pages(h, count, nid, n_mask); return err ? err : len; }
NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by first determining whether it should be allocated in the stack or dinamically depending on NODES_SHIFT. Right now, it goes the dynamic path whenever the nodemask_t is above 32 bytes. Although we could bump it to a reasonable value, the largest a nodemask_t can get is 128 bytes, so since __nr_hugepages_store_common is called from a rather shore stack we can just get rid of the NODEMASK_ALLOC call here. This reduces some code churn and complexity. Signed-off-by: Oscar Salvador <osalvador@suse.de> --- mm/hugetlb.c | 36 +++++++++++------------------------- 1 file changed, 11 insertions(+), 25 deletions(-)