These fixes were needed to bring my udl devices to life on v5.1-rc1.
Reza Arbab (2):
drm/udl: Fix off-by-one error in udl_get_edid()
drm/fb-helper: Do not scale depth down to 0
drivers/gpu/drm/drm_fb_helper.c | 6 +-
drivers/gpu/drm/udl/udl_connector.c | 2 +-
2 files changed, 6
On Thu, Jun 21, 2018 at 10:32:58AM +0200, Michal Hocko wrote:
[Cc Reza Arbab - I remember he was able to hit some bugs in memblock
registration code when I was reworking that area previously]
Thanks for the heads-up!
I have verified that this patchset doesn't seem to cause any regression
On Thu, Jun 21, 2018 at 10:32:58AM +0200, Michal Hocko wrote:
[Cc Reza Arbab - I remember he was able to hit some bugs in memblock
registration code when I was reworking that area previously]
Thanks for the heads-up!
I have verified that this patchset doesn't seem to cause any regression
00 0x0 0x4000>;
hotpluggable;
:
}
This is subtly different from the earlier example. This memory IS
present at boot. The hotpluggable property ensures that it resides in
ZONE_MOVABLE so it can potentially be removed.
--
Reza Arbab
00 0x0 0x4000>;
hotpluggable;
:
}
This is subtly different from the earlier example. This memory IS
present at boot. The hotpluggable property ensures that it resides in
ZONE_MOVABLE so it can potentially be removed.
--
Reza Arbab
li...@redhat.com>
Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com>
---
mm/migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index dea0ceb..c4546cc 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2146,8 +2146,8 @@ static int migrate_
The intention here is to set the same array element in src and dst.
Switch the order of these lines so that migrate->npages is only
incremented after we've used it.
Fixes: 8315ada7f095 ("mm/migrate: allow migrate_vma() to alloc new page on
empty entry")
Cc: Jérôme Glisse
Signed
On Tue, Sep 26, 2017 at 04:32:41PM +, Michal Hocko wrote:
On Tue 26-09-17 09:47:10, Reza Arbab wrote:
On Tue, Sep 26, 2017 at 01:37:07PM +, Michal Hocko wrote:
> On Fri 22-09-17 15:13:56, Reza Arbab wrote:
> > The move_pages() syscall can be used to find the numa node whe
On Tue, Sep 26, 2017 at 04:32:41PM +, Michal Hocko wrote:
On Tue 26-09-17 09:47:10, Reza Arbab wrote:
On Tue, Sep 26, 2017 at 01:37:07PM +, Michal Hocko wrote:
> On Fri 22-09-17 15:13:56, Reza Arbab wrote:
> > The move_pages() syscall can be used to find the numa node whe
On Tue, Sep 26, 2017 at 01:37:07PM +, Michal Hocko wrote:
On Fri 22-09-17 15:13:56, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT (unmapped
On Tue, Sep 26, 2017 at 01:37:07PM +, Michal Hocko wrote:
On Fri 22-09-17 15:13:56, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT (unmapped
On Fri, Sep 22, 2017 at 08:31:57PM +, Reza Arbab wrote:
On Fri, Sep 22, 2017 at 08:13:56PM +, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT
On Fri, Sep 22, 2017 at 08:31:57PM +, Reza Arbab wrote:
On Fri, Sep 22, 2017 at 08:13:56PM +, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT
On Fri, Sep 22, 2017 at 08:13:56PM +, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT (unmapped or zero page).
Argh. Please disregard this patch
On Fri, Sep 22, 2017 at 08:13:56PM +, Reza Arbab wrote:
The move_pages() syscall can be used to find the numa node where a page
currently resides. This is not working for device public memory pages,
which erroneously report -EFAULT (unmapped or zero page).
Argh. Please disregard this patch
be done unconditionally, but adding a
flag seems like a safer change.
Cc: Jérôme Glisse <jgli...@redhat.com>
Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com>
---
include/linux/mm.h | 1 +
mm/gup.c | 2 +-
mm/migrate.c | 2 +-
3 files changed, 3 insertions(+),
be done unconditionally, but adding a
flag seems like a safer change.
Cc: Jérôme Glisse
Signed-off-by: Reza Arbab
---
include/linux/mm.h | 1 +
mm/gup.c | 2 +-
mm/migrate.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux
] system_call+0x58/0x6c
The pfn causing this is the very last one. Correct the bounds check
accordingly.
Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent
with CPU")
Cc: Jérôme Glisse <jgli...@redhat.com>
Signed-off-by: Reza Arbab <ar...@linux.vn
] system_call+0x58/0x6c
The pfn causing this is the very last one. Correct the bounds check
accordingly.
Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent
with CPU")
Cc: Jérôme Glisse
Signed-off-by: Reza Arbab
---
mm/memory.c | 2 +-
1 file changed, 1 inser
el and movable online type explicitly and MMOP_ONLINE_KEEP becomes
a catch all default behavior.
Acked-by: Joonsoo Kim <iamjoonsoo....@lge.com>
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
Cc: <linux-...@vger.kernel.org>
Signed-off-by: Michal Hocko <mho...@suse.com>
--
Reza Arbab
el and movable online type explicitly and MMOP_ONLINE_KEEP becomes
a catch all default behavior.
Acked-by: Joonsoo Kim
Acked-by: Reza Arbab
Cc:
Signed-off-by: Michal Hocko
--
Reza Arbab
ll node though (except for Node0 which is special and
never goes away completely). If this turns out to be a problem in the
real life we can tweak the code to store hotplug flag into memblocks
but let's keep this simple now.
Signed-off-by: Michal Hocko <mho...@suse.com>
Acked-by: R
ll node though (except for Node0 which is special and
never goes away completely). If this turns out to be a problem in the
real life we can tweak the code to store hotplug flag into memblocks
but let's keep this simple now.
Signed-off-by: Michal Hocko
Acked-by: Reza Arbab
--
Reza Arbab
continue;
+
+ node_set(nid, node_possible_map);
+ }
+
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
--
Reza Arbab
continue;
+
+ node_set(nid, node_possible_map);
+ }
+
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
--
Reza Arbab
On Thu, Jun 01, 2017 at 06:14:54PM +0200, Michal Hocko wrote:
On Thu 01-06-17 11:02:28, Reza Arbab wrote:
On Thu, Jun 01, 2017 at 02:20:04PM +0200, Michal Hocko wrote:
>Teach move_pfn_range that MMOP_ONLINE_KEEP can use the movable zone if
>movable_node is enabled and the range doesn't o
On Thu, Jun 01, 2017 at 06:14:54PM +0200, Michal Hocko wrote:
On Thu 01-06-17 11:02:28, Reza Arbab wrote:
On Thu, Jun 01, 2017 at 02:20:04PM +0200, Michal Hocko wrote:
>Teach move_pfn_range that MMOP_ONLINE_KEEP can use the movable zone if
>movable_node is enabled and the range doesn't o
On Thu, Jun 01, 2017 at 05:52:31PM +0200, Michal Hocko wrote:
On Thu 01-06-17 10:47:46, Reza Arbab wrote:
On Thu, Jun 01, 2017 at 05:38:38PM +0200, Michal Hocko wrote:
>On Thu 01-06-17 10:19:36, Reza Arbab wrote:
>>The x86 SRAT (or the dt, on other platforms) can descri
On Thu, Jun 01, 2017 at 05:52:31PM +0200, Michal Hocko wrote:
On Thu 01-06-17 10:47:46, Reza Arbab wrote:
On Thu, Jun 01, 2017 at 05:38:38PM +0200, Michal Hocko wrote:
>On Thu 01-06-17 10:19:36, Reza Arbab wrote:
>>The x86 SRAT (or the dt, on other platforms) can descri
it. If your distro has some auto-onlining udev rule like
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
You could get things onlined as movable just by putting movable_node in
the boot params, without changing/modifying the rule.
--
Reza Arbab
it. If your distro has some auto-onlining udev rule like
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
You could get things onlined as movable just by putting movable_node in
the boot params, without changing/modifying the rule.
--
Reza Arbab
On Thu, Jun 01, 2017 at 05:38:38PM +0200, Michal Hocko wrote:
On Thu 01-06-17 10:19:36, Reza Arbab wrote:
The x86 SRAT (or the dt, on other platforms) can describe memory as
hotpluggable. See memblock_mark_hotplug(). That's only for memory present at
boot, though.
Yes but lose
On Thu, Jun 01, 2017 at 05:38:38PM +0200, Michal Hocko wrote:
On Thu 01-06-17 10:19:36, Reza Arbab wrote:
The x86 SRAT (or the dt, on other platforms) can describe memory as
hotpluggable. See memblock_mark_hotplug(). That's only for memory present at
boot, though.
Yes but lose
hotpluggable. There's no need to check for that
marking/description.
--
Reza Arbab
hotpluggable. There's no need to check for that
marking/description.
--
Reza Arbab
to memory_hotplug.
To make it more entertaining the kernel parameter is ignored unless
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y because we do not have the node
information for each memblock otherwise. So let's warn when the option
is disabled.
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
to memory_hotplug.
To make it more entertaining the kernel parameter is ignored unless
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y because we do not have the node
information for each memblock otherwise. So let's warn when the option
is disabled.
Acked-by: Reza Arbab
--
Reza Arbab
On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
Reza Arbab <ar...@linux.vnet.ibm.com> writes:
On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:
In practice, we never see a system with 256 NUMA nodes, and i
On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
Reza Arbab writes:
On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:
In practice, we never see a system with 256 NUMA nodes, and in fact, we
do not support node
...@gmail.com
--
Reza Arbab
...@gmail.com
--
Reza Arbab
cto always enabled. This shouldn't introduce any
change to the semantic.
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
cto always enabled. This shouldn't introduce any
change to the semantic.
Acked-by: Reza Arbab
--
Reza Arbab
really liking all this cleanup of the memory hotplug code. Thanks!
Much appreciated.
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
really liking all this cleanup of the memory hotplug code. Thanks!
Much appreciated.
Acked-by: Reza Arbab
--
Reza Arbab
On Tue, May 23, 2017 at 05:44:23PM -0500, Michael Bringmann wrote:
On 05/23/2017 04:49 PM, Reza Arbab wrote:
On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
On 05/23/2017 10:52 AM, Reza Arbab wrote:
On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
+static
On Tue, May 23, 2017 at 05:44:23PM -0500, Michael Bringmann wrote:
On 05/23/2017 04:49 PM, Reza Arbab wrote:
On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
On 05/23/2017 10:52 AM, Reza Arbab wrote:
On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
+static
On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
On 05/23/2017 10:52 AM, Reza Arbab wrote:
On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
+static void setup_nodes(void)
+{
+int i, l = 32 /* MAX_NUMNODES */;
+
+for (i = 0; i < l
On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
On 05/23/2017 10:52 AM, Reza Arbab wrote:
On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
+static void setup_nodes(void)
+{
+int i, l = 32 /* MAX_NUMNODES */;
+
+for (i = 0; i < l
of this patch.
Migration to private device memory will be useful for device that
have large pool of such like GPU, NVidia plans to use HMM for that.
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
of this patch.
Migration to private device memory will be useful for device that
have large pool of such like GPU, NVidia plans to use HMM for that.
Acked-by: Reza Arbab
--
Reza Arbab
.kernel.org/r/1479253501-26261-1-git-send-email-bsinghar...@gmail.com
(see patch 3/3)
--
Reza Arbab
.kernel.org/r/1479253501-26261-1-git-send-email-bsinghar...@gmail.com
(see patch 3/3)
--
Reza Arbab
as to warn of a situation that
has since been enabled.
Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com>
---
Aside: The "per-node stats" are still printed under the first populated
zone, but that's not necessarily the first stanza any more. I'm not sure
which criteria is
as to warn of a situation that
has since been enabled.
Signed-off-by: Reza Arbab
---
Aside: The "per-node stats" are still printed under the first populated
zone, but that's not necessarily the first stanza any more. I'm not sure
which criteria is more important with regard to
LL, 0, 0);
+
+ migrate_ctx->ops->finalize_and_map(migrate_ctx);
+
+ /* Unlock and remap pages */
+ migrate_dma_finalize(migrate_ctx);
+
+ return 0;
+}
+EXPORT_SYMBOL(migrate_dma);
--
Reza Arbab
LL, 0, 0);
+
+ migrate_ctx->ops->finalize_and_map(migrate_ctx);
+
+ /* Unlock and remap pages */
+ migrate_dma_finalize(migrate_ctx);
+
+ return 0;
+}
+EXPORT_SYMBOL(migrate_dma);
--
Reza Arbab
-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
-by: Reza Arbab
--
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
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
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
attempts
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
attempts
rt_pfn which caused my removal crash. Except here I'm not sure
the correct place to splice in and set it.
--
Reza Arbab
rt_pfn which caused my removal crash. Except here I'm not sure
the correct place to splice in and set it.
--
Reza Arbab
pages = max(start_pfn + nr_pages, old_end_pfn) -
pgdat->node_start_pfn;
---
Along these lines, maybe we should also do
- if (start_pfn < zone->zone_start_pfn)
+ if (zone_is_empty(zone) || start_pfn < zone->zone_start_pfn)
in resize_zone_range()?
--
Reza Arbab
pages = max(start_pfn + nr_pages, old_end_pfn) -
pgdat->node_start_pfn;
---
Along these lines, maybe we should also do
- if (start_pfn < zone->zone_start_pfn)
+ if (zone_is_empty(zone) || start_pfn < zone->zone_start_pfn)
in resize_zone_range()?
--
Reza Arbab
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
/sys/devices/system
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
/sys/devices/system
k to the oops in find_biggest_section_pfn().
--
Reza Arbab
k to the oops in find_biggest_section_pfn().
--
Reza Arbab
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
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
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
= 0x0
find_biggest_section_pfn loop: pfn=0x, sec_nr = 0xff
Unable to handle kernel paging request for data at address 0xc00080f19e78
--
Reza Arbab
= 0x0
find_biggest_section_pfn loop: pfn=0x, sec_nr = 0xff
Unable to handle kernel paging request for data at address 0xc00080f19e78
--
Reza Arbab
:15: warning: unused variable ‘page’ [-Wunused-variable]
--
Reza Arbab
:15: warning: unused variable ‘page’ [-Wunused-variable]
--
Reza Arbab
- page = pfn_to_page(pfn);
- if (!page_initialized(page))
- return -1;
return pfn_to_nid(pfn);
}
Verified that /sys/devices/system/node/nodeX/memoryY links are there now.
--
Reza Arbab
return -1;
return pfn_to_nid(pfn);
}
Verified that /sys/devices/system/node/nodeX/memoryY links are there now.
--
Reza Arbab
() returns int, but callers ignore it.
Is that worth cleaning up? If so, should the implementations be
simplified, or should we maybe do a pr_error() or something with it?
--
Reza Arbab
() returns int, but callers ignore it.
Is that worth cleaning up? If so, should the implementations be
simplified, or should we maybe do a pr_error() or something with it?
--
Reza Arbab
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
less
node, it shows up in node 0 instead. I'm digging to see if I can help
narrow down where things go wrong.
--
Reza Arbab
less
node, it shows up in node 0 instead. I'm digging to see if I can help
narrow down where things go wrong.
--
Reza Arbab
on a range of virtual address and thus by
doing migration in chunk that can be large enough to use DMA engine or
special copy offloading engine.
Reviewed-by: Reza Arbab <ar...@linux.vnet.ibm.com>
Tested-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
on a range of virtual address and thus by
doing migration in chunk that can be large enough to use DMA engine or
special copy offloading engine.
Reviewed-by: Reza Arbab
Tested-by: Reza Arbab
--
Reza Arbab
into this area the more WTF code I see. This has seen
close to zero review and seems to be building up more single usecase
code on top of previous. We need to change this, seriously!
No argument here. I'm happy to help however I can.
--
Reza Arbab
into this area the more WTF code I see. This has seen
close to zero review and seems to be building up more single usecase
code on top of previous. We need to change this, seriously!
No argument here. I'm happy to help however I can.
--
Reza Arbab
is very
nonintuitive.
--
Reza Arbab
is very
nonintuitive.
--
Reza Arbab
an 'int online_type', ala online_pages().
That way we could specify offline, online, online+movable, etc.
--
Reza Arbab
an 'int online_type', ala online_pages().
That way we could specify offline, online, online+movable, etc.
--
Reza Arbab
aving chimed in.
Just sent a Tested-by for that part of v17.
--
Reza Arbab
.
--
Reza Arbab
since v14. So for what it's worth,
Acked-by: Reza Arbab <ar...@linux.vnet.ibm.com>
Tested-by: Reza Arbab <ar...@linux.vnet.ibm.com>
--
Reza Arbab
since v14. So for what it's worth,
Acked-by: Reza Arbab
Tested-by: Reza Arbab
--
Reza Arbab
return 0;
Isn't it implied that ranges printed this way are [start, end)?
If not, the entire file should be fixed, not just this occurrence.
--
Reza Arbab
1 - 100 of 287 matches
Mail list logo
