On Wed, Aug 29, 2018 at 11:09:01PM +, Pasha Tatashin wrote:
> Hi Oscar,
>
> I have been studying this patch, and do not see anything bad about it
> except that it begs to be split into smaller patches. I think you can
> send this work as a series without RFC if this patch is split into 3 or
>
On Wed, Aug 29, 2018 at 11:09:01PM +, Pasha Tatashin wrote:
> Hi Oscar,
>
> I have been studying this patch, and do not see anything bad about it
> except that it begs to be split into smaller patches. I think you can
> send this work as a series without RFC if this patch is split into 3 or
>
On 8/17/18 11:41 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> Currently, we decrement zone/node spanned_pages when we
> remove memory and not when we offline it.
>
> This, besides of not being consistent with the current code,
> implies that we can access steal pages if we never get to
On 8/17/18 11:41 AM, Oscar Salvador wrote:
> From: Oscar Salvador
>
> Currently, we decrement zone/node spanned_pages when we
> remove memory and not when we offline it.
>
> This, besides of not being consistent with the current code,
> implies that we can access steal pages if we never get to
On 22.08.2018 09:50, Oscar Salvador wrote:
> On Tue, Aug 21, 2018 at 03:17:10PM +0200, David Hildenbrand wrote:
>>> add_device_memory is in charge of
>>
>> I wouldn't use the terminology of onlining/offlining here. That applies
>> rather to memory that is exposed to the rest of the system (e.g.
On 22.08.2018 09:50, Oscar Salvador wrote:
> On Tue, Aug 21, 2018 at 03:17:10PM +0200, David Hildenbrand wrote:
>>> add_device_memory is in charge of
>>
>> I wouldn't use the terminology of onlining/offlining here. That applies
>> rather to memory that is exposed to the rest of the system (e.g.
On Tue, Aug 21, 2018 at 03:17:10PM +0200, David Hildenbrand wrote:
> > add_device_memory is in charge of
>
> I wouldn't use the terminology of onlining/offlining here. That applies
> rather to memory that is exposed to the rest of the system (e.g. buddy
> allocator, has underlying memory block
On Tue, Aug 21, 2018 at 03:17:10PM +0200, David Hildenbrand wrote:
> > add_device_memory is in charge of
>
> I wouldn't use the terminology of onlining/offlining here. That applies
> rather to memory that is exposed to the rest of the system (e.g. buddy
> allocator, has underlying memory block
> add_device_memory is in charge of
I wouldn't use the terminology of onlining/offlining here. That applies
rather to memory that is exposed to the rest of the system (e.g. buddy
allocator, has underlying memory block devices). I guess it is rather a
pure setup/teardown of that device memory.
>
> add_device_memory is in charge of
I wouldn't use the terminology of onlining/offlining here. That applies
rather to memory that is exposed to the rest of the system (e.g. buddy
allocator, has underlying memory block devices). I guess it is rather a
pure setup/teardown of that device memory.
>
From: Oscar Salvador
Currently, we decrement zone/node spanned_pages when we
remove memory and not when we offline it.
This, besides of not being consistent with the current code,
implies that we can access steal pages if we never get to online
that memory.
In order to prevent that, we have to
From: Oscar Salvador
Currently, we decrement zone/node spanned_pages when we
remove memory and not when we offline it.
This, besides of not being consistent with the current code,
implies that we can access steal pages if we never get to online
that memory.
In order to prevent that, we have to
12 matches
Mail list logo
