On Thu, Apr 06, 2017 at 07:12:42PM +0200, Michal Hocko wrote:
> > ---8<---
> > mm, vmscan: prevent kswapd sleeping prematurely due to mismatched
> > classzone_idx -fix
> >
> > The patch "mm, vmscan: prevent kswapd sleeping prematurely due to mismatched
> > classzone_idx" has different initial
On Thu, Apr 06, 2017 at 07:12:42PM +0200, Michal Hocko wrote:
> > ---8<---
> > mm, vmscan: prevent kswapd sleeping prematurely due to mismatched
> > classzone_idx -fix
> >
> > The patch "mm, vmscan: prevent kswapd sleeping prematurely due to mismatched
> > classzone_idx" has different initial
On Thu 06-04-17 17:55:20, Mel Gorman wrote:
> On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> > > This was my first time using your git branch instead of applying the
> > > patches
> > > from this thread to v4.11-rc5 myself.
> >
> > OK, so this looks like another thing to
On Thu 06-04-17 17:55:20, Mel Gorman wrote:
> On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> > > This was my first time using your git branch instead of applying the
> > > patches
> > > from this thread to v4.11-rc5 myself.
> >
> > OK, so this looks like another thing to
On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> > This was my first time using your git branch instead of applying the patches
> > from this thread to v4.11-rc5 myself.
>
> OK, so this looks like another thing to resolve. I have seen this
> warning as well but I didn't consider it
On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> > This was my first time using your git branch instead of applying the patches
> > from this thread to v4.11-rc5 myself.
>
> OK, so this looks like another thing to resolve. I have seen this
> warning as well but I didn't consider it
On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> On Thu 06-04-17 10:46:53, Reza Arbab wrote:
> > On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
> > >On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> > >>On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >
On Thu, Apr 06, 2017 at 06:21:55PM +0200, Michal Hocko wrote:
> On Thu 06-04-17 10:46:53, Reza Arbab wrote:
> > On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
> > >On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> > >>On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >
On Thu 06-04-17 10:46:53, Reza Arbab wrote:
> On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
> >On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> >>On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >>>OK, so after recent change mostly driven by testing from Reza Arbab
>
On Thu 06-04-17 10:46:53, Reza Arbab wrote:
> On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
> >On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> >>On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >>>OK, so after recent change mostly driven by testing from Reza Arbab
>
On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
On Thu 06-04-17 10:24:49, Reza Arbab wrote:
On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
>OK, so after recent change mostly driven by testing from Reza Arbab
>(thanks again) I believe I am getting to a working state
On Thu, Apr 06, 2017 at 05:41:28PM +0200, Michal Hocko wrote:
On Thu 06-04-17 10:24:49, Reza Arbab wrote:
On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
>OK, so after recent change mostly driven by testing from Reza Arbab
>(thanks again) I believe I am getting to a working state
On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >OK, so after recent change mostly driven by testing from Reza Arbab
> >(thanks again) I believe I am getting to a working state finally. All I
> >currently have is
> >in
On Thu 06-04-17 10:24:49, Reza Arbab wrote:
> On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
> >OK, so after recent change mostly driven by testing from Reza Arbab
> >(thanks again) I believe I am getting to a working state finally. All I
> >currently have is
> >in
On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
OK, so after recent change mostly driven by testing from Reza Arbab
(thanks again) I believe I am getting to a working state finally. All I
currently have is
in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
On Thu, Apr 06, 2017 at 03:08:46PM +0200, Michal Hocko wrote:
OK, so after recent change mostly driven by testing from Reza Arbab
(thanks again) I believe I am getting to a working state finally. All I
currently have is
in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
OK, so after recent change mostly driven by testing from Reza Arbab
(thanks again) I believe I am getting to a working state finally. All I
currently have is
in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
attempts/rewrite-mem_hotplug-WIP branch. I will highly appreciate more
OK, so after recent change mostly driven by testing from Reza Arbab
(thanks again) I believe I am getting to a working state finally. All I
currently have is
in git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
attempts/rewrite-mem_hotplug-WIP branch. I will highly appreciate more
On Wed 05-04-17 23:02:14, Michal Hocko wrote:
[...]
> OK, I was staring into the code and I guess I finally understand what is
> going on here. Looking at arch_add_memory->...->register_mem_sect_under_node
> was just misleading. I am still not 100% sure why but we try to do the
> same thing later
On Wed 05-04-17 23:02:14, Michal Hocko wrote:
[...]
> OK, I was staring into the code and I guess I finally understand what is
> going on here. Looking at arch_add_memory->...->register_mem_sect_under_node
> was just misleading. I am still not 100% sure why but we try to do the
> same thing later
On Wed 05-04-17 18:34:39, Michal Hocko wrote:
> On Wed 05-04-17 10:48:52, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
> > >On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> > >>Okay, getting further. With this I can again repeatedly add and remove,
> > >>but now
On Wed 05-04-17 18:34:39, Michal Hocko wrote:
> On Wed 05-04-17 10:48:52, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
> > >On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> > >>Okay, getting further. With this I can again repeatedly add and remove,
> > >>but now
On Wed 05-04-17 20:15:02, Michal Hocko wrote:
> On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> > >But one thing that is really bugging me is how could you see low pfns in
> > >the previous oops. Please drop the last patch and
On Wed 05-04-17 20:15:02, Michal Hocko wrote:
> On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> > >But one thing that is really bugging me is how could you see low pfns in
> > >the previous oops. Please drop the last patch and
On Wed, Apr 05, 2017 at 06:34:39PM +0200, Michal Hocko wrote:
This is really interesting. Because add_memory_resource does the
following
/* call arch's memory hotadd */
ret = arch_add_memory(nid, start, size);
if (ret < 0)
goto error;
/* we
On Wed, Apr 05, 2017 at 06:34:39PM +0200, Michal Hocko wrote:
This is really interesting. Because add_memory_resource does the
following
/* call arch's memory hotadd */
ret = arch_add_memory(nid, start, size);
if (ret < 0)
goto error;
/* we
On Wed 05-04-17 20:15:02, Michal Hocko wrote:
> On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> > >But one thing that is really bugging me is how could you see low pfns in
> > >the previous oops. Please drop the last patch and
On Wed 05-04-17 20:15:02, Michal Hocko wrote:
> On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> > On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> > >But one thing that is really bugging me is how could you see low pfns in
> > >the previous oops. Please drop the last patch and
On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> >But one thing that is really bugging me is how could you see low pfns in
> >the previous oops. Please drop the last patch and sprinkle printks down
> >the remove_memory path to see where
On Wed 05-04-17 12:32:49, Reza Arbab wrote:
> On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
> >But one thing that is really bugging me is how could you see low pfns in
> >the previous oops. Please drop the last patch and sprinkle printks down
> >the remove_memory path to see where
On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
But one thing that is really bugging me is how could you see low pfns
in the previous oops. Please drop the last patch and sprinkle printks
down the remove_memory path to see where this all go south. I believe
that there is
On Wed, Apr 05, 2017 at 05:42:59PM +0200, Michal Hocko wrote:
But one thing that is really bugging me is how could you see low pfns
in the previous oops. Please drop the last patch and sprinkle printks
down the remove_memory path to see where this all go south. I believe
that there is
On Wed 05-04-17 10:48:52, Reza Arbab wrote:
> On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> >>Okay, getting further. With this I can again repeatedly add and remove,
> >>but now I'm seeing a weird variation of that earlier issue:
>
On Wed 05-04-17 10:48:52, Reza Arbab wrote:
> On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> >>Okay, getting further. With this I can again repeatedly add and remove,
> >>but now I'm seeing a weird variation of that earlier issue:
>
On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
Okay, getting further. With this I can again repeatedly add and
remove, but now I'm seeing a weird variation of that earlier issue:
1. add_memory(), online_movable
On Wed, Apr 05, 2017 at 08:42:39AM +0200, Michal Hocko wrote:
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
Okay, getting further. With this I can again repeatedly add and
remove, but now I'm seeing a weird variation of that earlier issue:
1. add_memory(), online_movable
On Wed 05-04-17 09:53:05, Reza Arbab wrote:
[...]
> I hope this made sense. :/
yes it certainly helped me to make some picture of your setup. I will
keep thinking about that. But one thing that is really bugging me is
how could you see low pfns in the previous oops. Please drop the last
patch and
On Wed 05-04-17 09:53:05, Reza Arbab wrote:
[...]
> I hope this made sense. :/
yes it certainly helped me to make some picture of your setup. I will
keep thinking about that. But one thing that is really bugging me is
how could you see low pfns in the previous oops. Please drop the last
patch and
On Wed, Apr 05, 2017 at 03:52:49PM +0200, Michal Hocko wrote:
My code doesn't do that though. So I guess I have to sanitize. Does
this help? Please drop the "mm, memory_hotplug: get rid of zone/node
shrinking" patch.
---
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index
On Wed, Apr 05, 2017 at 03:52:49PM +0200, Michal Hocko wrote:
My code doesn't do that though. So I guess I have to sanitize. Does
this help? Please drop the "mm, memory_hotplug: get rid of zone/node
shrinking" patch.
---
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index
On Wed, Apr 05, 2017 at 11:24:27AM +0200, Michal Hocko wrote:
On Wed 05-04-17 08:42:39, Michal Hocko wrote:
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> It's new. Without this patchset, I can repeatedly
> add_memory()->online_movable->offline->remove_memory() all of a node's
> memory.
This is
On Wed, Apr 05, 2017 at 11:24:27AM +0200, Michal Hocko wrote:
On Wed 05-04-17 08:42:39, Michal Hocko wrote:
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> It's new. Without this patchset, I can repeatedly
> add_memory()->online_movable->offline->remove_memory() all of a node's
> memory.
This is
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> >>I think I found another edge case. You
> >>get an oops when removing all of a node's memory:
> >>
> >>__nr_to_section
> >>__pfn_to_section
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> >>I think I found another edge case. You
> >>get an oops when removing all of a node's memory:
> >>
> >>__nr_to_section
> >>__pfn_to_section
On Wed 05-04-17 08:42:39, Michal Hocko wrote:
> On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> > On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> > >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> > >>I think I found another edge case. You
> > >>get an oops when removing all of a
On Wed 05-04-17 08:42:39, Michal Hocko wrote:
> On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> > On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> > >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> > >>I think I found another edge case. You
> > >>get an oops when removing all of a
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> >>I think I found another edge case. You
> >>get an oops when removing all of a node's memory:
> >>
> >>__nr_to_section
> >>__pfn_to_section
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> >>I think I found another edge case. You
> >>get an oops when removing all of a node's memory:
> >>
> >>__nr_to_section
> >>__pfn_to_section
On Tue 04-04-17 21:41:22, Michal Hocko wrote:
> On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> > On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
> > >Thanks for your testing! This is highly appreciated.
> > >Can I assume your Tested-by?
> >
> > Of course! Not quite done, though.
>
On Tue 04-04-17 21:41:22, Michal Hocko wrote:
> On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> > On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
> > >Thanks for your testing! This is highly appreciated.
> > >Can I assume your Tested-by?
> >
> > Of course! Not quite done, though.
>
On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
On Tue 04-04-17 13:30:13, Reza Arbab wrote:
I think I found another edge case. You
get an oops when removing all of a node's memory:
__nr_to_section
__pfn_to_section
find_biggest_section_pfn
shrink_pgdat_span
__remove_zone
On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
On Tue 04-04-17 13:30:13, Reza Arbab wrote:
I think I found another edge case. You
get an oops when removing all of a node's memory:
__nr_to_section
__pfn_to_section
find_biggest_section_pfn
shrink_pgdat_span
__remove_zone
On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
> >Thanks for your testing! This is highly appreciated.
> >Can I assume your Tested-by?
>
> Of course! Not quite done, though.
Ohh, I didn't mean to rush you to that!
> I think I found
On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
> >Thanks for your testing! This is highly appreciated.
> >Can I assume your Tested-by?
>
> Of course! Not quite done, though.
Ohh, I didn't mean to rush you to that!
> I think I found
On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
Thanks for your testing! This is highly appreciated.
Can I assume your Tested-by?
Of course! Not quite done, though. I think I found another edge case.
You get an oops when removing all of a node's memory:
__nr_to_section
On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
Thanks for your testing! This is highly appreciated.
Can I assume your Tested-by?
Of course! Not quite done, though. I think I found another edge case.
You get an oops when removing all of a node's memory:
__nr_to_section
On Tue 04-04-17 11:02:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
> >diff --git a/drivers/base/node.c b/drivers/base/node.c
> >index 5548f9686016..ee080a35e869 100644
> >--- a/drivers/base/node.c
> >+++ b/drivers/base/node.c
> >@@ -368,8 +368,6 @@ int
On Tue 04-04-17 11:02:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
> >diff --git a/drivers/base/node.c b/drivers/base/node.c
> >index 5548f9686016..ee080a35e869 100644
> >--- a/drivers/base/node.c
> >+++ b/drivers/base/node.c
> >@@ -368,8 +368,6 @@ int
On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 5548f9686016..ee080a35e869 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -368,8 +368,6 @@ int unregister_cpu_under_node(unsigned int cpu, unsigned
int nid)
On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 5548f9686016..ee080a35e869 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -368,8 +368,6 @@ int unregister_cpu_under_node(unsigned int cpu, unsigned
int nid)
On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
OK, so I've been thinkin about that and I believe that page_initialized
check in get_nid_for_pfn is just bogus. There is nothing to rely on the
page::lru to be already initialized. So I will go with the following as
a separate
On Tue, Apr 04, 2017 at 10:23:02AM +0200, Michal Hocko wrote:
OK, so I've been thinkin about that and I believe that page_initialized
check in get_nid_for_pfn is just bogus. There is nothing to rely on the
page::lru to be already initialized. So I will go with the following as
a separate
On Tue 04-04-17 09:34:12, Michal Hocko wrote:
> On Tue 04-04-17 09:23:29, Michal Hocko wrote:
> > [Let's add Gary who as introduced this code c04fc586c1a48]
>
> OK, so Gary's email doesn't exist anymore. Does anybody can comment on
> this? I suspect this code is just-in-case... Mel?
>
> > On
On Tue 04-04-17 09:34:12, Michal Hocko wrote:
> On Tue 04-04-17 09:23:29, Michal Hocko wrote:
> > [Let's add Gary who as introduced this code c04fc586c1a48]
>
> OK, so Gary's email doesn't exist anymore. Does anybody can comment on
> this? I suspect this code is just-in-case... Mel?
>
> > On
On Tue 04-04-17 09:23:29, Michal Hocko wrote:
> [Let's add Gary who as introduced this code c04fc586c1a48]
OK, so Gary's email doesn't exist anymore. Does anybody can comment on
this? I suspect this code is just-in-case... Mel?
> On Mon 03-04-17 15:42:13, Reza Arbab wrote:
[...]
> > Almost
On Tue 04-04-17 09:23:29, Michal Hocko wrote:
> [Let's add Gary who as introduced this code c04fc586c1a48]
OK, so Gary's email doesn't exist anymore. Does anybody can comment on
this? I suspect this code is just-in-case... Mel?
> On Mon 03-04-17 15:42:13, Reza Arbab wrote:
[...]
> > Almost
[Let's add Gary who as introduced this code c04fc586c1a48]
On Mon 03-04-17 15:42:13, Reza Arbab wrote:
> On Mon, Apr 03, 2017 at 10:23:38PM +0200, Michal Hocko wrote:
> >On Mon 03-04-17 14:58:30, Reza Arbab wrote:
> >>However, I am seeing a regression. When adding memory to a memoryless
> >>node,
[Let's add Gary who as introduced this code c04fc586c1a48]
On Mon 03-04-17 15:42:13, Reza Arbab wrote:
> On Mon, Apr 03, 2017 at 10:23:38PM +0200, Michal Hocko wrote:
> >On Mon 03-04-17 14:58:30, Reza Arbab wrote:
> >>However, I am seeing a regression. When adding memory to a memoryless
> >>node,
On Mon, Apr 03, 2017 at 10:23:38PM +0200, Michal Hocko wrote:
On Mon 03-04-17 14:58:30, Reza Arbab wrote:
However, I am seeing a regression. When adding memory to a memoryless
node, it shows up in node 0 instead. I'm digging to see if I can help
narrow down where things go wrong.
OK, I guess
On Mon, Apr 03, 2017 at 10:23:38PM +0200, Michal Hocko wrote:
On Mon 03-04-17 14:58:30, Reza Arbab wrote:
However, I am seeing a regression. When adding memory to a memoryless
node, it shows up in node 0 instead. I'm digging to see if I can help
narrow down where things go wrong.
OK, I guess
On Mon 03-04-17 14:58:30, Reza Arbab wrote:
> On Mon, Apr 03, 2017 at 01:55:46PM +0200, Michal Hocko wrote:
> >Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
> >who have shaped this code last few years. Also Igor and Vitaly seem to be
> >using memory hotplug in
On Mon 03-04-17 14:58:30, Reza Arbab wrote:
> On Mon, Apr 03, 2017 at 01:55:46PM +0200, Michal Hocko wrote:
> >Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
> >who have shaped this code last few years. Also Igor and Vitaly seem to be
> >using memory hotplug in
On Mon, Apr 03, 2017 at 01:55:46PM +0200, Michal Hocko wrote:
Anyting? I would really appreciate a feedback from IBM and Futjitsu
guys who have shaped this code last few years. Also Igor and Vitaly
seem to be using memory hotplug in virtualized environments. I do not
expect they would see a
On Mon, Apr 03, 2017 at 01:55:46PM +0200, Michal Hocko wrote:
Anyting? I would really appreciate a feedback from IBM and Futjitsu
guys who have shaped this code last few years. Also Igor and Vitaly
seem to be using memory hotplug in virtualized environments. I do not
expect they would see a
On Mon, 3 Apr 2017 13:55:46 +0200
Michal Hocko wrote:
> On Thu 30-03-17 13:54:48, Michal Hocko wrote:
> [...]
> > Any thoughts, complains, suggestions?
>
> Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
> who have shaped this code last few years.
On Mon, 3 Apr 2017 13:55:46 +0200
Michal Hocko wrote:
> On Thu 30-03-17 13:54:48, Michal Hocko wrote:
> [...]
> > Any thoughts, complains, suggestions?
>
> Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
> who have shaped this code last few years. Also Igor and Vitaly
On Thu 30-03-17 13:54:48, Michal Hocko wrote:
[...]
> Any thoughts, complains, suggestions?
Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
who have shaped this code last few years. Also Igor and Vitaly seem to
be using memory hotplug in virtualized environments. I do not
On Thu 30-03-17 13:54:48, Michal Hocko wrote:
[...]
> Any thoughts, complains, suggestions?
Anyting? I would really appreciate a feedback from IBM and Futjitsu guys
who have shaped this code last few years. Also Igor and Vitaly seem to
be using memory hotplug in virtualized environments. I do not
On Fri 31-03-17 21:19:24, Heiko Carstens wrote:
> On Thu, Mar 30, 2017 at 01:54:48PM +0200, Michal Hocko wrote:
> > Patch 5 is the core of the change. In order to make it easier to review
> > I have tried it to be as minimalistic as possible and the large code
> > removal is moved to patch 6.
> >
On Fri 31-03-17 21:19:24, Heiko Carstens wrote:
> On Thu, Mar 30, 2017 at 01:54:48PM +0200, Michal Hocko wrote:
> > Patch 5 is the core of the change. In order to make it easier to review
> > I have tried it to be as minimalistic as possible and the large code
> > removal is moved to patch 6.
> >
On Thu, Mar 30, 2017 at 01:54:48PM +0200, Michal Hocko wrote:
> Patch 5 is the core of the change. In order to make it easier to review
> I have tried it to be as minimalistic as possible and the large code
> removal is moved to patch 6.
>
> I would appreciate if s390 folks could take a look at
On Thu, Mar 30, 2017 at 01:54:48PM +0200, Michal Hocko wrote:
> Patch 5 is the core of the change. In order to make it easier to review
> I have tried it to be as minimalistic as possible and the large code
> removal is moved to patch 6.
>
> I would appreciate if s390 folks could take a look at
Hi,
I have posted a crude RFC for this rework [1] and there didn't seem any
objections so I have split up the patch into smaller chunks which will
make the review easier hopefully.
Motivation:
Movable onlining is a real hack with many downsides - mainly
reintroduction of lowmem/highmem issues we
Hi,
I have posted a crude RFC for this rework [1] and there didn't seem any
objections so I have split up the patch into smaller chunks which will
make the review easier hopefully.
Motivation:
Movable onlining is a real hack with many downsides - mainly
reintroduction of lowmem/highmem issues we
84 matches
Mail list logo