On Fri, Dec 29, 2017 at 01:23:05PM +0100, Michal Hocko wrote:
Hi Michal,
>Always make sure to CC linux-api mailing list when proposing user
>visible API patches.
Sorry for that, since scripts/get_maintainer.pl didn't show that,
so I don't know should Cc that.
>
>On Wed 27-12-17 20:30:12, Chao F
Always make sure to CC linux-api mailing list when proposing user
visible API patches.
On Wed 27-12-17 20:30:12, Chao Fan wrote:
> In sometimes users specify the memory region in immovable node in
> some kernel commandline, such as "kernel_core" or the "immovable_mem="
> in the patchset that I hav
On Wed, Dec 27, 2017 at 01:47:26PM +0100, Greg KH wrote:
>On Wed, Dec 27, 2017 at 08:30:12PM +0800, Chao Fan wrote:
>> In sometimes users specify the memory region in immovable node in
>> some kernel commandline, such as "kernel_core" or the "immovable_mem="
>> in the patchset that I have send. But
On Wed, Dec 27, 2017 at 08:30:12PM +0800, Chao Fan wrote:
> In sometimes users specify the memory region in immovable node in
> some kernel commandline, such as "kernel_core" or the "immovable_mem="
> in the patchset that I have send. But users don't know the memory
> region. So add this interface
The result in my virtual machine looks like this:
[root@localhost ~]# cat /sys/devices/system/memory/immovable_mem
a@0,1f30@10,1f40@1f40,1f40@3e80,1f40@5dc0,1f40@7d00,1f40@9c40,480@bb80,1ac0@1,1f40@11ac0,1f40@13a00
In sometimes users specify the memory region in immovable node in
some kernel commandline, such as "kernel_core" or the "immovable_mem="
in the patchset that I have send. But users don't know the memory
region. So add this interface to print it.
It will show like this: "nn@ss,nn@ss,...". "nn" mean
Hi Florian,
thanks for your message. Please, find the replies in-line.
On Wed, Mar 29, 2017 at 05:40:02PM -0700, Florian Fainelli wrote:
> While the "hack" that sets/clears NOMAP in order for pfn_valid() to
> return false/true when appropriate during __add_pages() definitively
> does seem to work
Hi Andrea, Maciej,
On 02/06/2017 03:17 AM, Andrea Reale wrote:
> Hi Scott,
> Hi all,
>
> in reply to the issues that Scott reported last month, myself and Maciej
> investigated further by running quite a number of experiments on the
> physical and virtual environments we have avaialable.
>
> We
Hi Andrea,
On 17-02-06 03:17 AM, Andrea Reale wrote:
Hi Scott,
Hi all,
in reply to the issues that Scott reported last month, myself and Maciej
investigated further by running quite a number of experiments on the
physical and virtual environments we have avaialable.
We collected all the result
Hi Scott,
Hi all,
in reply to the issues that Scott reported last month, myself and Maciej
investigated further by running quite a number of experiments on the
physical and virtual environments we have avaialable.
We collected all the results and relevant logs in a Web page at
https://hotplug-tes
Hi Maciej,
On 16-12-21 01:44 AM, Maciej Bielski wrote:
Hi Scott,
Thanks for testing it and providing us the feedback. For replicating the
problem you have reported,
could you provide more info on your system configuration, please?
Among others, few questions that we have in mind are:
* What is
Hi Scott,
Thanks for testing it and providing us the feedback. For replicating the
problem you have reported,
could you provide more info on your system configuration, please?
Among others, few questions that we have in mind are:
* What is the RAM size at boot? Is it multiple of 1GB (or precisely
Hi Maciej,
I have applied that patch ontop of the patches I previously sent out
and tested.
It does recognized the memory in /proc/iomem but I get memory corruption
of the original system RAM soon after. It appears the page allocation
gets corrupted. I will try to dig into it further but if
On 2016/12/16 2:31, Andrea Reale wrote:
> Hi Xishi Qiu,
>
> thanks for your comments.
>
> The short anwser to your question is the following. As you hinted,
> it is related to the way pfn_valid() is implemented in arm64 when
> CONFIG_HAVE_ARCH_PFN_VALID is true (default), i.e., just a check fo
Hi Xishi Qiu,
thanks for your comments.
The short anwser to your question is the following. As you hinted,
it is related to the way pfn_valid() is implemented in arm64 when
CONFIG_HAVE_ARCH_PFN_VALID is true (default), i.e., just a check for
the NOMAP flags on the corresponding memblocks.
Sinc
On 2016/12/15 14:18, Xishi Qiu wrote:
> On 2016/12/14 20:16, Maciej Bielski wrote:
>
>>
>>
>> -#ifdef CONFIG_MEMORY_HOTREMOVE
>> -int arch_remove_memory(u64 start, u64 size)
>> -{
>> -unsigned long start_pfn = start >> PAGE_SHIFT;
>> -unsigned long nr_pages = size >> PAGE_SHIFT;
>> -
On 2016/12/14 20:16, Maciej Bielski wrote:
>
>
> -#ifdef CONFIG_MEMORY_HOTREMOVE
> -int arch_remove_memory(u64 start, u64 size)
> -{
> - unsigned long start_pfn = start >> PAGE_SHIFT;
> - unsigned long nr_pages = size >> PAGE_SHIFT;
> - struct zone *zone;
> - int ret;
> +
This patch relates to the work previously announced in [1]. This builds on the
work by Scott Branden [2] and, henceforth, it needs to be applied on top of
Scott's patches [2]. Comments are very welcome.
Changes from the original patchset and known issues:
- Compared to Scott's original patchset
At 2012/7/23 19:06, Vasilis Liaskovitis Wrote:
Hi,
On Mon, Jul 23, 2012 at 05:08:04PM +0800, Wen Congyang wrote:
+static int memblock_state_notifier_nb(struct notifier_block *nb, unsigned long
+ val, void *v)
+{
+ struct memory_notify *arg = (struct memory_notify *)v;
+
Hi,
On Mon, Jul 23, 2012 at 05:08:04PM +0800, Wen Congyang wrote:
> > +static int memblock_state_notifier_nb(struct notifier_block *nb, unsigned
> > long
> > + val, void *v)
> > +{
> > + struct memory_notify *arg = (struct memory_notify *)v;
> > + struct memory_block *mem = NULL;
>
At 07/20/2012 07:18 PM, Vasilis Liaskovitis Wrote:
> hot-remove initiated by acpi_memhotplug driver tries to offline pages and then
> remove section/sysfs files in remove_memory(). remove_memory() will only
> proceed
> if is_memblk_offline() returns true, i.e. only if the corresponding memblock
>
hot-remove initiated by acpi_memhotplug driver tries to offline pages and then
remove section/sysfs files in remove_memory(). remove_memory() will only proceed
if is_memblk_offline() returns true, i.e. only if the corresponding memblock
is in MEM_OFFLINE state. However, the memblock state is curren
On Fri, 18 Feb 2005, Dave Hansen wrote:
Memory hot-remove isn't really needed with Xen, the balloon
driver takes care of that.
You can free up individual pages back to the hypervisor, but you might
also want the opportunity to free up some unused mem_map if you shrink
the partition by a large amoun
On Fri, 2005-02-18 at 16:52 -0500, Rik van Riel wrote:
> On Thu, 17 Feb 2005, Dave Hansen wrote:
> > The attached patch is a prototype implementation of memory hot-add. It
> > allows you to boot your system, and add memory to it later. Why would
> > you want to do this?
>
> I want it so I can gr
On Thu, 17 Feb 2005, Dave Hansen wrote:
The attached patch is a prototype implementation of memory hot-add. It
allows you to boot your system, and add memory to it later. Why would
you want to do this?
I want it so I can grow Xen guests after they have been booted
up. Being able to hot-add memor
The attached patch is a prototype implementation of memory hot-add. It
allows you to boot your system, and add memory to it later. Why would
you want to do this? Well, it's a step before memory removal which can
help cope with things like bad RAM. This is primarily useful for a
machine that you
26 matches
Mail list logo
