[RFC] depopulate_range_driver_managed() for removing page-table mappings for hot-added memory blocks

[RFC] depopulate_range_driver_managed() for removing page-table mappings for hot-added memory blocks

[Sudarshan Rajagopalan]

Hello,

When memory blocks are removed, along with removing the memmap entries, 
memory resource and memory block devices, the arch specific 
arch_remove_memory() is called which takes care of tearing down the 
page-tables.

Suppose there’s a usecase where the removed memory blocks will be added 
back into the system at later point, we can remove/offline the block in 
a way that all entries such as memmaps, memory resources and block 
devices can be kept intact so that they won’t be needed to be created 
again when blocks are added back. Now this can be done by doing offline 
alone. But if there’s special usecase where the page-table entries are 
needed to be teared down when blocks are offlined in order to avoid 
speculative accesses on offlined memory region, but also keep the memmap 
entries and block devices intact, I was thinking if we can implement 
something like {populate|depopulate}_range_driver_managed() that can be 
called after online/offline which can create/tear down page table 
mappings for that range. This would avoid us from the need to do 
remove_memory() entirely just for the sake of page-table entries being 
removed. We can now just offline the block and call 
depopulate_range_driver_managed.

This basically isolates arch_{add/remove}_memory outside of 
add/remove_memory routines so that drivers can choose if it needs to 
just offline and remove page-table mappings or hotremove memory 
entirely. This gives drivers the flexibility to retain memmap entries 
and memory resource and block device creation so that they can be 
skipped when blocks are added back – this helps us reduce the latencies 
for removing and adding memory blocks.

I’m still in the process the creating the patch that implements this, 
which would give clear view about this RFC but just putting out the 
thought here if it makes sense or not.


Sudarshan
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC] depopulate_range_driver_managed() for removing page-table mappings for hot-added memory blocks

[Christoph Hellwig]

On Fri, Nov 13, 2020 at 06:41:22PM -0800, Sudarshan Rajagopalan wrote:
> 
> Hello,
> 
> When memory blocks are removed, along with removing the memmap entries,
> memory resource and memory block devices, the arch specific
> arch_remove_memory() is called which takes care of tearing down the
> page-tables.
> 
> Suppose there???s a usecase where the removed memory blocks will be added
> back into the system at later point,

Stop this crap.  If you have a use case post the actual use here,
including code and specs.  If you don't have that don't waste peoples
time on your pipe dream.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC] depopulate_range_driver_managed() for removing page-table mappings for hot-added memory blocks

[David Hildenbrand]

On 14.11.20 11:28, Christoph Hellwig wrote:
> On Fri, Nov 13, 2020 at 06:41:22PM -0800, Sudarshan Rajagopalan wrote:
>>
>> Hello,
>>
>> When memory blocks are removed, along with removing the memmap entries,
>> memory resource and memory block devices, the arch specific
>> arch_remove_memory() is called which takes care of tearing down the
>> page-tables.
>>
>> Suppose there???s a usecase where the removed memory blocks will be added
>> back into the system at later point,
> 
> Stop this crap.  If you have a use case post the actual use here,
> including code and specs.  If you don't have that don't waste peoples
> time on your pipe dream.
> 

Adding to that, we (upstream people) are not interested in introducing 
and maintaining kernel interfaces/infrastructure only relevant to 
out-of-tree / proprietary drivers. If you're planning on upstreaming, 
then please share the actual problem you are trying to solve and the 
issues you see with the current interfaces/infrastructure, best along 
with an RFC that shows the bigger picture.

Having that said, what you describe sounds more like a special kind of 
allocation, whereby the linear mapping is removed, similar to [1].

[1] https://lkml.kernel.org/r/20201111145322.15793-1-david@redhat.com


-- 
Thanks,

David / dhildenb


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel