On 3/6/19 1:41 AM, Oscar Salvador wrote:
> On Mon, Mar 04, 2019 at 08:15:40PM -0800, Mike Kravetz wrote:
>> In addition, the code in __nr_hugepages_store_common() which tries to
>> handle the case of not being able to allocate a node mask would likely
>> result in incorrect behavior. Luckily, it i
On Mon, Mar 04, 2019 at 08:15:40PM -0800, Mike Kravetz wrote:
> In addition, the code in __nr_hugepages_store_common() which tries to
> handle the case of not being able to allocate a node mask would likely
> result in incorrect behavior. Luckily, it is very unlikely we will
> ever take this path.
On 3/5/19 4:35 PM, Mike Kravetz wrote:
On 3/5/19 1:16 PM, Andrew Morton wrote:
On Mon, 4 Mar 2019 20:15:40 -0800 Mike Kravetz wrote:
Andrew, this is on top of Alexandre Ghiti's "hugetlb: allow to free gigantic
pages regardless of the configuration" patch. Both patches modify
__nr_hugepages_s
On 3/5/19 1:16 PM, Andrew Morton wrote:
> On Mon, 4 Mar 2019 20:15:40 -0800 Mike Kravetz
> wrote:
>
>> Andrew, this is on top of Alexandre Ghiti's "hugetlb: allow to free gigantic
>> pages regardless of the configuration" patch. Both patches modify
>> __nr_hugepages_store_common(). Alex's patc
On Mon, 4 Mar 2019 20:15:40 -0800 Mike Kravetz wrote:
> Andrew, this is on top of Alexandre Ghiti's "hugetlb: allow to free gigantic
> pages regardless of the configuration" patch. Both patches modify
> __nr_hugepages_store_common(). Alex's patch is going to change slightly
> in this area.
OK,
On 3/4/19 4:03 PM, Naoya Horiguchi wrote:
> On Tue, Feb 26, 2019 at 04:03:23PM -0800, Mike Kravetz wrote:
>> On 2/26/19 2:36 PM, Andrew Morton wrote:
> ...
+ } else {
/*
- * per node hstate attribute: adjust count to global,
- * but restrict
On Tue, Feb 26, 2019 at 04:03:23PM -0800, Mike Kravetz wrote:
> On 2/26/19 2:36 PM, Andrew Morton wrote:
...
> >>
> >> + } else {
> >>/*
> >> - * per node hstate attribute: adjust count to global,
> >> - * but restrict alloc/free to the specified node.
> >> +
On Tue, Feb 26, 2019 at 04:03:23PM -0800, Mike Kravetz wrote:
> I was just going to update the comments and send you a new patch, but
> but your comment got me thinking about this situation. I did not really
> change the way this code operates. As a reminder, the original code is like:
>
> NODEM
On Tue, Feb 26, 2019 at 11:32:24AM -0800, Mike Kravetz wrote:
> On 2/25/19 10:21 PM, David Rientjes wrote:
> > On Tue, 26 Feb 2019, Jing Xiangfeng wrote:
> >> On 2019/2/26 3:17, David Rientjes wrote:
> >>> On Mon, 25 Feb 2019, Mike Kravetz wrote:
> >>>
> Ok, what about just moving the calculat
On 2/26/19 2:36 PM, Andrew Morton wrote:
>> ...
>>
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -2274,7 +2274,7 @@ static int adjust_pool_surplus(struct hstate *h,
>> nodemask_t *nodes_allowed,
>
> Please tweak that email client to prevent the wordwraps.
Sorry about that.
>> +/*
>> +
>
> The number of node specific huge pages can be set via a file such as:
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> When a node specific value is specified, the global number of huge
> pages must also be adjusted. This adjustment is calculated as the
> specified n
On 2/25/19 10:21 PM, David Rientjes wrote:
> On Tue, 26 Feb 2019, Jing Xiangfeng wrote:
>> On 2019/2/26 3:17, David Rientjes wrote:
>>> On Mon, 25 Feb 2019, Mike Kravetz wrote:
>>>
Ok, what about just moving the calculation/check inside the lock as in the
untested patch below?
S
On Tue, 26 Feb 2019, Jing Xiangfeng wrote:
> On 2019/2/26 3:17, David Rientjes wrote:
> > On Mon, 25 Feb 2019, Mike Kravetz wrote:
> >
> >> Ok, what about just moving the calculation/check inside the lock as in the
> >> untested patch below?
> >>
> >> Signed-off-by: Mike Kravetz
> >> ---
> >> m
On 2019/2/26 3:17, David Rientjes wrote:
> On Mon, 25 Feb 2019, Mike Kravetz wrote:
>
>> Ok, what about just moving the calculation/check inside the lock as in the
>> untested patch below?
>>
>> Signed-off-by: Mike Kravetz
>> ---
>> mm/hugetlb.c | 34 ++
>> 1 file
On Mon, 25 Feb 2019, Mike Kravetz wrote:
> Ok, what about just moving the calculation/check inside the lock as in the
> untested patch below?
>
> Signed-off-by: Mike Kravetz
> ---
> mm/hugetlb.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> dif
> On 2/24/19 7:17 PM, David Rientjes wrote:
>> On Sun, 24 Feb 2019, Mike Kravetz wrote:
@@ -2423,7 +2423,14 @@ static ssize_t __nr_hugepages_store_common(bool
obey_mempolicy,
* per node hstate attribute: adjust count to global,
* but restrict alloc/free
On 2/24/19 7:17 PM, David Rientjes wrote:
> On Sun, 24 Feb 2019, Mike Kravetz wrote:
>
>>> User can change a node specific hugetlb count. i.e.
>>> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
>>> the calculated value of count is a total number of huge pages. It could
>>>
On Sun, 24 Feb 2019, Mike Kravetz wrote:
> > User can change a node specific hugetlb count. i.e.
> > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> > the calculated value of count is a total number of huge pages. It could
> > be overflow when a user entering a crazy high
On 2/22/19 5:32 PM, Jing Xiangfeng wrote:
> User can change a node specific hugetlb count. i.e.
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
> the calculated value of count is a total number of huge pages. It could
> be overflow when a user entering a crazy high value. I
User can change a node specific hugetlb count. i.e.
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
the calculated value of count is a total number of huge pages. It could
be overflow when a user entering a crazy high value. If so, the total
number of huge pages could be a sm
20 matches
Mail list logo
