On 24.09.20 23:50, Dan Williams wrote:
> On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote:
>>
>>
>>
>>> Am 24.09.2020 um 23:26 schrieb Dan Williams :
>>>
>>> [..]
> I'm not suggesting to busy the whole "virtio" range, just the portion
> that's about to be passed to add_memory_drive
On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote:
>
>
>
> > Am 24.09.2020 um 23:26 schrieb Dan Williams :
> >
> > [..]
> >>> I'm not suggesting to busy the whole "virtio" range, just the portion
> >>> that's about to be passed to add_memory_driver_managed().
> >>
> >> I'm afraid I don't ge
> Am 24.09.2020 um 23:26 schrieb Dan Williams :
>
> [..]
>>> I'm not suggesting to busy the whole "virtio" range, just the portion
>>> that's about to be passed to add_memory_driver_managed().
>>
>> I'm afraid I don't get your point. For virtio-mem:
>>
>> Before:
>>
>> 1. Create virtio0 cont
[..]
> > I'm not suggesting to busy the whole "virtio" range, just the portion
> > that's about to be passed to add_memory_driver_managed().
>
> I'm afraid I don't get your point. For virtio-mem:
>
> Before:
>
> 1. Create virtio0 container resource
>
> 2. (somewhen in the future) add_memory_driver_
On 24.09.20 15:54, Dan Williams wrote:
> On Thu, Sep 24, 2020 at 12:26 AM David Hildenbrand wrote:
>>
>> On 23.09.20 23:41, Dan Williams wrote:
>>> On Wed, Sep 23, 2020 at 1:04 AM David Hildenbrand wrote:
On 08.09.20 17:33, Joao Martins wrote:
> [Sorry for the late response]
>
>
On Thu, Sep 24, 2020 at 12:26 AM David Hildenbrand wrote:
>
> On 23.09.20 23:41, Dan Williams wrote:
> > On Wed, Sep 23, 2020 at 1:04 AM David Hildenbrand wrote:
> >>
> >> On 08.09.20 17:33, Joao Martins wrote:
> >>> [Sorry for the late response]
> >>>
> >>> On 8/21/20 11:06 AM, David Hildenbrand
On 23.09.20 23:41, Dan Williams wrote:
> On Wed, Sep 23, 2020 at 1:04 AM David Hildenbrand wrote:
>>
>> On 08.09.20 17:33, Joao Martins wrote:
>>> [Sorry for the late response]
>>>
>>> On 8/21/20 11:06 AM, David Hildenbrand wrote:
On 03.08.20 07:03, Dan Williams wrote:
> @@ -37,109 +45,94
On Wed, Sep 23, 2020 at 1:04 AM David Hildenbrand wrote:
>
> On 08.09.20 17:33, Joao Martins wrote:
> > [Sorry for the late response]
> >
> > On 8/21/20 11:06 AM, David Hildenbrand wrote:
> >> On 03.08.20 07:03, Dan Williams wrote:
> >>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *d
On 08.09.20 17:33, Joao Martins wrote:
> [Sorry for the late response]
>
> On 8/21/20 11:06 AM, David Hildenbrand wrote:
>> On 03.08.20 07:03, Dan Williams wrote:
>>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>>> * could be mixed in a node with faster memory, causing
>>>
[Sorry for the late response]
On 8/21/20 11:06 AM, David Hildenbrand wrote:
> On 03.08.20 07:03, Dan Williams wrote:
>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>> * could be mixed in a node with faster memory, causing
>> * unavoidable performance issues.
>>
>>> + release_mem_region(range.start, range_len(&range));
>>
>> remove_memory() does a release_mem_region_adjustable(). Don't you
>> actually want to release the *unaligned* region you requested?
>>
> Isn't it what we're doing here?
> (The release_mem_region_adjustable() is using the same
On 03.08.20 07:03, Dan Williams wrote:
> Several related issues around this unneeded attribute:
>
> - The dax_kmem_res property allows the kmem driver to stash the adjusted
> resource range that was used for the hotplug operation, but that can be
> recalculated from the original base range.
>
12 matches
Mail list logo
