On 08.08.23 08:29, Aneesh Kumar K V wrote:
On 8/8/23 12:05 AM, David Hildenbrand wrote:
On 07.08.23 14:41, David Hildenbrand wrote:
On 07.08.23 14:27, Michal Hocko wrote:
On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
[...]
Do you see a need for firmware-managed memory to be hotplugged in
On 8/8/23 12:05 AM, David Hildenbrand wrote:
> On 07.08.23 14:41, David Hildenbrand wrote:
>> On 07.08.23 14:27, Michal Hocko wrote:
>>> On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
>>> [...]
Do you see a need for firmware-managed memory to be hotplugged in with
different memory
On 8/8/23 12:05 AM, David Hildenbrand wrote:
> On 07.08.23 14:41, David Hildenbrand wrote:
>> On 07.08.23 14:27, Michal Hocko wrote:
>>> On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
>>> [...]
Do you see a need for firmware-managed memory to be hotplugged in with
different memory
On 07.08.23 14:41, David Hildenbrand wrote:
On 07.08.23 14:27, Michal Hocko wrote:
On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
[...]
Do you see a need for firmware-managed memory to be hotplugged in with
different memory block sizes?
In short. Yes. Slightly longer, a fixed size memory
On 03.08.23 13:30, Michal Hocko wrote:
On Thu 03-08-23 11:24:08, David Hildenbrand wrote:
[...]
would be readable only when the block is offline and it would reallocate
vmemmap on the change. Makes sense? Are there any risks? Maybe pfn
walkers?
The question is: is it of any real value such
On 07.08.23 14:27, Michal Hocko wrote:
On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
[...]
Do you see a need for firmware-managed memory to be hotplugged in with
different memory block sizes?
In short. Yes. Slightly longer, a fixed size memory block semantic is
just standing in the way
On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
[...]
> Do you see a need for firmware-managed memory to be hotplugged in with
> different memory block sizes?
In short. Yes. Slightly longer, a fixed size memory block semantic is
just standing in the way and I would even argue it is actively
On 8/3/23 5:00 PM, Michal Hocko wrote:
> On Thu 03-08-23 11:24:08, David Hildenbrand wrote:
> [...]
>>> would be readable only when the block is offline and it would reallocate
>>> vmemmap on the change. Makes sense? Are there any risks? Maybe pfn
>>> walkers?
>>
>> The question is: is it of any
On 03.08.23 10:52, Michal Hocko wrote:
On Wed 02-08-23 18:59:04, Michal Hocko wrote:
On Wed 02-08-23 17:54:04, David Hildenbrand wrote:
On 02.08.23 17:50, Michal Hocko wrote:
On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
On 8/1/23 4:20 PM, Michal Hocko wrote:
On Tue 01-08-23 14:58:29,
On Wed 02-08-23 18:59:04, Michal Hocko wrote:
> On Wed 02-08-23 17:54:04, David Hildenbrand wrote:
> > On 02.08.23 17:50, Michal Hocko wrote:
> > > On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
> > > > On 8/1/23 4:20 PM, Michal Hocko wrote:
> > > > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V
On Wed 02-08-23 17:54:04, David Hildenbrand wrote:
> On 02.08.23 17:50, Michal Hocko wrote:
> > On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
> > > On 8/1/23 4:20 PM, Michal Hocko wrote:
> > > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
> > > > > On 8/1/23 2:28 PM, Michal Hocko wrote:
On Wed, 2023-08-02 at 21:27 +0530, Aneesh Kumar K V wrote:
> On 8/2/23 9:24 PM, David Hildenbrand wrote:
> > On 02.08.23 17:50, Michal Hocko wrote:
> > > On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
> > > > On 8/1/23 4:20 PM, Michal Hocko wrote:
> > > > > On Tue 01-08-23 14:58:29, Aneesh
On 8/2/23 9:24 PM, David Hildenbrand wrote:
> On 02.08.23 17:50, Michal Hocko wrote:
>> On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
>>> On 8/1/23 4:20 PM, Michal Hocko wrote:
On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
> On 8/1/23 2:28 PM, Michal Hocko wrote:
>> On Tue
On 02.08.23 17:50, Michal Hocko wrote:
On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
On 8/1/23 4:20 PM, Michal Hocko wrote:
On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
On 8/1/23 2:28 PM, Michal Hocko wrote:
On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
Allow updating
On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
> On 8/1/23 4:20 PM, Michal Hocko wrote:
> > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
> >> On 8/1/23 2:28 PM, Michal Hocko wrote:
> >>> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
> Allow updating memmap_on_memory mode after the
On 8/1/23 4:20 PM, Michal Hocko wrote:
> On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
>> On 8/1/23 2:28 PM, Michal Hocko wrote:
>>> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
Allow updating memmap_on_memory mode after the kernel boot. Memory
hotplug done after the mode update
On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
> On 8/1/23 2:28 PM, Michal Hocko wrote:
> > On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
> >> Allow updating memmap_on_memory mode after the kernel boot. Memory
> >> hotplug done after the mode update will use the new mmemap_on_memory
> >>
On 8/1/23 2:28 PM, Michal Hocko wrote:
> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
>> Allow updating memmap_on_memory mode after the kernel boot. Memory
>> hotplug done after the mode update will use the new mmemap_on_memory
>> value.
>
> Well, this is a user space kABI extension and as
On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
> Allow updating memmap_on_memory mode after the kernel boot. Memory
> hotplug done after the mode update will use the new mmemap_on_memory
> value.
Well, this is a user space kABI extension and as such you should spend
more words about the
Allow updating memmap_on_memory mode after the kernel boot. Memory
hotplug done after the mode update will use the new mmemap_on_memory
value.
Acked-by: David Hildenbrand
Signed-off-by: Aneesh Kumar K.V
---
mm/memory_hotplug.c | 33 +
1 file changed, 17
20 matches
Mail list logo
