Re: [PATCH v2 1/4] kernel/resource: Introduce managed SOFT RESERVED resources

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/22/2025 12:03 AM, Fan Ni wrote:
> On Tue, Jan 21, 2025 at 12:57:19PM -0600, Fontenot, Nathan wrote:
>>
>>
>> On 1/21/2025 2:19 AM, David Hildenbrand wrote:
>>> On 16.01.25 18:42, Nathan Fontenot wrote:
>>>
>>> Hi,
>>>
>>>> Introduce the ability to manage SOFT RESERVED kernel resources prior to
>>>> these resources being  placed in the iomem resource tree. This provides
>>>> the ability for drivers to update SOFT RESERVED resources that intersect
>>>> with their memory resources.
>>>>
>>>> During boot, any resources marked as IORES_DESC_SOFT_RESERVED are placed
>>>> on the soft reserve resource tree. Once boot completes all resources
>>>> are placed on the iomem resource tree. This behavior is gated by a new
>>>> kernel option CONFIG_SOFT_RESERVED_MANAGED.
>>>>
>>>
>>> I'm missing a bit of context here.
>>>
>>> Why can't we flag these regions in the existing iomem tree, where they can be fixed up (even after boot?)?
>>>
>>> Especially, what about deferred driver loading after boot? Why is that not a concern or why can we reliably handle everything "during boot" ?
>>
>> That's a good question and one I should have addressed.
>>
>> The goal is to prevent the dax driver from creating dax devices for soft reserve
>> resources prior to the soft reserve resources being updated for any intersecting
>> cxl regions.
> 
> Not an export. Can you explain a little more here?
> What is the problem if we only flag the resources as "soft
> reserved" in the iomem tree without creating a separate tree, and
> process the "soft reserved" resources only when needed? 

The issue we currently encounter is that the dax driver consumes these soft reserve
resources and creates dax devices for the soft reserve resources before the cxl driver
comnpletes device probe and can update the soft reserve resources to remove any
intersections with cxl regions. We do not want these soft reserves consumed prior
to them being updated.

If we were to put the soft reserves on the iomem tree we would need to have the
cxl driver provide a notification that it has completed updates and others (i.e. dax)
can them go process the soft reserve resources.

-Nathan

> 
> Fan
>>
>> During boot the dax hmem driver walks the iomem tree to save off a copy of all
>> soft reserve resources. The dax driver then later walks this copy to create
>> dax devices for the soft reserve regions. This occurs before the cxl drivers
>> load, create cxl regions, and update any intersecting soft reserve resources.
>>
>> To prevent this the soft reserves are set aside on a separate list during boot
>> so that they can be updated (if needed) and later added to the iomem resource tree.
>> The dax driver is then notified of any soft reserves added to the iomem tree
>> so that it may consume them.
>>
>> Hopefully that answers your question. I'll include this in the next version.
>>
>> -Nathan
>>
>>>
>>>> As part of this update two new interfaces are added for management of
>>>> the SOFT RESERVED resources. The release_srmem_region_adjustable()
>>>> routine allows for removing pieces of SOFT RESERVED resources. The
>>>> the merge_srmem_resources() allows drivers to merge any remaining SOFT
>>>> RESERVED resources into the iomem resource tree once updatea are complete.
>>>>
>>>> Signed-off-by: Nathan Fontenot <nathan.fontenot@xxxxxxx>
>>>
>>





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux