ing the bug/feature we
have been discussing which has eventually led to my realising a big
improvement in my display. Also to all those who support open-source
software, without which a user would not be able to taylor his system to
match what he needs so well.
With best wishes,
Roger.
Section "
is not binding on either of you.)
I would be glad to hear what you eventually decide between you.
Many thanks indeed for your help !
Roger.
ble by the driver, but just give a warning in the logs.
(But I do understand that you will also need to consider other points of
view.)
I'll confirm the result of the above test shortly.
Thanks,
Roger.
way beyond my competence), I note that in the old module
mga_vga_mode_valid is made known to other parts of the system in a
different way than mgag200_mode_config_mode_valid is in the new module
(and indeed they have different parameter types). (Might this be
relevant ?)
Best wishes,
Roger.
Sect
, but hopefully the attached logs will help
you work out why the old kernel permitted the high bandwidth mode I
always use (despite returning MODE_BAD) and the new kernel doesn't.
(The "old" kernel is 9.1, i.e. 5.14.0-162.6.1.el9_1.0.1, and "new"
kernel is 9.2, i.e. 5.14.0-28
on[2366]: (==) modeset(0): RGB weight 888
in case it makes a difference.
Thanks,
Roger.
but Xorg still lists it under
Settings->Display (and Wayland doesn't). With the increased bandwidth
module in place it tells me 1440x900 is on the list. I think this is as
you expect as far as the kernel rather than Xorg is concerned.
Thanks,
Roger.
r (if it is indeed true - I haven't
looked at the Xorg source code at all).
The issue from the point of view of my usage case is that the chip works
just fine in the 1440x900@60Hz mode, even though 30318019 > 1024*24400.
If I haven't made anything sufficiently clear, or if you need more info,
please ask.
Best wishes,
Roger.
t; the chip family).
> > > >
> > > > But the swiotlb isn't per device, but system global.
> > >
> > > Sure, but if the swiotlb is in use, then you can't really use the GPU.
> > > So you get to pick one.
> >
> > The swiotlb is used only for buffers which are not within the DMA mask of a
> > device (see dma_direct_map_page()). So an AMD GPU supporting a 44 bit DMA
> > mask
> > won't use the swiotlb unless you have a buffer above guest physical address
> > of
> > 16TB (so basically never).
> >
> > Disabling swiotlb in such a guest would OTOH mean, that a device with only
> > 32 bit DMA mask passed through to this guest couldn't work with buffers
> > above 4GB.
> >
> > I don't think this is acceptable.
>
> From the Xen subsystem in Linux point of view, the only thing we need to
> do is to make sure *not* to enable swiotlb_xen (yes "swiotlb_xen", not
> the global swiotlb) on PVH because it is not needed anyway.
But this is already the case on PVH, swiotlb_xen won't be enabled.
swiotlb_xen is only enabled for PV domains, other domain types don't
enable it under any circumstance on x86.
> I think we should leave the global "swiotlb" setting alone. The global
> swiotlb is not relevant to Xen anyway, and surely baremetal Linux has to
> have a way to deal with swiotlb/GPU incompatibilities.
>
> We just have to avoid making things worse on Xen, and for that we just
> need to avoid unconditionally enabling swiotlb-xen. If the Xen subsystem
> doesn't enable swiotlb_xen/swiotlb, and no other subsystem enables
> swiotlb, then we have a good Linux configuration capable of handling the
> GPU properly.
Given that this patch is basically a non-functional change (because
the modified functions are only called for PV domains) I think we all
agree that swiotlb_xen should never be used on PVH, and native swiotlb
might be required depending on the DMA address restrictions of the
devices on the system. So no change required.
Thanks, Roger.
lb_dma_ops)
Same here, this function is only called by
pcifront_connect_and_init_dma() and pcifront should never attach on a
PVH domain, hence it's also dead code.
Thanks, Roger.
tform. The text above make it look like GSI is some
kind of internal Xen reference to an interrupt, but it's not.
How does a PV domain deal with this? I would assume there Linux will
also end up with IRQ != GSI, and hence will need some kind of
translation?
Thanks, Roger.
to PHYSDEVOP_map_pirq
in the toolstack itself if the PIRQ cannot be found?
Thanks, Roger.
V domains handle addresses the same, so if
it's not needed for a PV dom0 it's likely not needed for a PV domU
either. Albeit it would help to know more about what
AMDGPU_PASSTHROUGH_MODE implies.
Thanks, Roger.
* beforehand to initialize xen_auto_xlat_grant_frames. */
Comment need to be updated, but I was thinking whether it won't be
best to simply call xen_pvh_gnttab_setup() from __gnttab_init() itself
when running as a PVH guest?
Thanks, Roger.
On Fri, Sep 04, 2020 at 09:00:18AM +0200, Jürgen Groß wrote:
> On 03.09.20 18:38, Roger Pau Monné wrote:
> > On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
> > > On 01.09.20 10:33, Roger Pau Monne wrote:
> > > > To be used in order to create f
On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
> On 01.09.20 10:33, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > order to create st
on some platforms.
Signed-off-by: Roger Pau Monné
---
Cc: Oleksandr Andrushchenko
Cc: David Airlie
Cc: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Dan Carpenter
Cc: Roger Pau Monne
Cc: Wei Liu
Cc: Yan Yankovskyi
Cc: dri-devel@lists.freedesktop.org
Cc
On Tue, Sep 01, 2020 at 10:33:26AM +0200, Roger Pau Monne wrote:
> +static int fill_list(unsigned int nr_pages)
> +{
> + struct dev_pagemap *pgmap;
> + void *vaddr;
> + unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
> + int nid, ret;
On Thu, Aug 13, 2020 at 08:33:37AM +0100, Christoph Hellwig wrote:
> On Tue, Aug 11, 2020 at 11:44:47AM +0200, Roger Pau Monne wrote:
> > If enabled (because ZONE_DEVICE is supported) the usage of the new
> > functionality untangles Xen balloon and RAM hotplug from the usage of
On Fri, Aug 14, 2020 at 02:54:38PM +0200, Jürgen Groß wrote:
> On 14.08.20 14:47, Roger Pau Monné wrote:
> > On Fri, Aug 14, 2020 at 12:27:32PM +0200, Jürgen Groß wrote:
> > > On 14.08.20 11:56, Roger Pau Monné wrote:
> > > > On Fri, Aug 14, 2020 at 08:29:20AM
On Fri, Aug 14, 2020 at 12:27:32PM +0200, Jürgen Groß wrote:
> On 14.08.20 11:56, Roger Pau Monné wrote:
> > On Fri, Aug 14, 2020 at 08:29:20AM +0100, Christoph Hellwig wrote:
> > > On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monn?? wrote:
> > > > On Thu, Au
On Fri, Aug 14, 2020 at 08:29:20AM +0100, Christoph Hellwig wrote:
> On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monn?? wrote:
> > On Thu, Aug 13, 2020 at 08:33:37AM +0100, Christoph Hellwig wrote:
> > > On Tue, Aug 11, 2020 at 11:44:47AM +0200, Roger Pau Monne wrote:
:
> On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monné wrote:
> > On Thu, Aug 13, 2020 at 08:33:37AM +0100, Christoph Hellwig wrote:
> > > On Tue, Aug 11, 2020 at 11:44:47AM +0200, Roger Pau Monne wrote:
> > > > If enabled (because ZONE_DEVICE is supported) the usage of
On Wed, Aug 12, 2020 at 09:28:45AM +0200, Jürgen Groß wrote:
> On 11.08.20 11:44, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > order to create st
on some platforms.
Signed-off-by: Roger Pau Monné
---
Cc: Oleksandr Andrushchenko
Cc: David Airlie
Cc: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Dan Carpenter
Cc: Roger Pau Monne
Cc: Wei Liu
Cc: Yan Yankovskyi
Cc: dri-devel@lists.freedesktop.org
Cc
On Tue, Jul 28, 2020 at 06:12:46PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 27/07/2020 10:13, Roger Pau Monne wr
On Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote:
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> >> Hi,
> >>
> >> On 27/07/2020 10:13, Roger Pau Monne wrote:
> >>>
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> Hi,
>
> On 27/07/2020 10:13, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > o
On Fri, Jul 24, 2020 at 12:36:33PM -0400, Boris Ostrovsky wrote:
> On 7/24/20 10:34 AM, David Hildenbrand wrote:
> > CCing Dan
> >
> > On 24.07.20 14:42, Roger Pau Monne wrote:
> >> +
> >> +#include
> >> +#include
> >>
hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Signed-off-by: Roger Pau Monné
---
I've not added a new memory_type type and just used
MEMORY_DEVICE_DEVDAX which
hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Signed-off-by: Roger Pau Monné
---
I've not added a new memory_type type and just used
MEMORY_DEVICE_DEVDAX which
>> 1))) {\
__x = round_up(x, y); \
} else {\
You probably want
if (!(__y & (__y - 1))
--
Roger
st memory space, isn't there any generic interface that
you can use?
If it's in host physical memory space, why do you need this buffer to
be contiguous in host physical memory space? The IOMMU should hide all
this.
Thanks, Roger.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 01:18 PM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > > Of Roger Pau Monné
&
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
> > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> > > > On Tue, Ap
Acked-by: Roger He <hongbo...@amd.com>
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Sunday, March 25, 2018 6:58 PM
To: linaro-mm-...@lists.linaro.org; linux-me...@vger.kernel.org;
dri-devel@lists.freedesktop.or
Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, March 16, 2018 9:21 PM
To: linaro-mm-...@lists.linaro.org; linux-me...@vger.kernel.org;
dri-devel@lists.freedeskt
On 15/03/18 13:46, Robin Murphy wrote:
> On 12/03/18 10:41, Roger Quadros wrote:
> [...]
>>>>> @@ -0,0 +1,75 @@
>>>>> +USB Connector
>>>>> +=
>>>>> +
>>>>> +USB connector node represent
Andrezej,
Why don't you have any of the USB maintainers in to/cc?
Greg Kroah-Hartman <gre...@linuxfoundation.org> (supporter:USB SUBSYSTEM)
Felipe Balbi <ba...@kernel.org> (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM)
On 12/03/18 09:02, Andrzej Hajda wrote:
> On 09.03.2018 11:24
remote-endpoint = <_usbc_hs>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + usb_con_ss: endpoint {
> + remote-endp
Patch 1,4,5: Acked-by: Roger He <hongbo...@amd.com>
Patch 2,3,6: Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Tuesday, March 06, 2018 10:4
Patch 1: Acked-by: Roger He <hongbo...@amd.com>
Patch 2~5: Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Monday, March 05, 2018 8:07 PM
To: dri-devel@lists.fre
o idea why you need all this.
I think the overview should contain at least:
1. A description of the problem you are trying to solve.
2. A high level description of the proposed solution.
3. How the proposed solution deals with the problem described in 1.
This overview is not useful for people that
Series is: Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Friday, February 23, 2018 8:25 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/ttm: c
I missed the Per-VM-BO share the reservation object with root bo. So context is
not NULL here.
So, this patch is:
Reviewed-by: Roger He <hongbo...@amd.com>
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Friday, Fe
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Friday, February 23, 2018 8:06 PM
To: He, Roger <hongbo...@amd.com>; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 3/4] d
_mem_limit as 0 to keep original behavior
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memory.c | 92
drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++
include/drm/
Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Tuesday, February 20, 2018 8:58 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
lin
true;
For the special case: when command submission with Per-VM-BO enabled,
All BOs a/b/c are always valid BO. After the validation of BOs a and b,
when validation of BO c, is it possible to return true and then evict BO a and
b by mistake ?
Because a/b/c share same task_struct.
Thanks
Roger(Hongbo.
looks good to me. Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Tuesday, February 20, 2018 8:58 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedeskt
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, February 22, 2018 10:06 PM
To: He, Roger <hongbo...@amd.com>
Cc: Koenig, Christian <christian.koe...@amd.com>;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if fr
Series is: Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Thursday, February 22, 2018 7:16 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 8/8] drm/bochs:
Series is: Reviewed-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Thursday, February 22, 2018 11:02 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 6/6] drm/ttm
-Original Message-
From: Koenig, Christian
Sent: Thursday, February 22, 2018 8:54 PM
To: He, Roger <hongbo...@amd.com>; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit
Am 22.02.2018 um 12:43 schrieb He,
-Original Message-
From: Koenig, Christian
Sent: Thursday, February 22, 2018 7:28 PM
To: He, Roger <hongbo...@amd.com>; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit
Am 22.02.2018 um 11:10 schrieb Roger He:
> the
, allow TTM
allocation.
v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
v5: add an attribute for lower_mem_limit
Signed-off-by
r substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote:
> On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
> > On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/xen/xen_drm_
el.com]
Sent: Friday, February 16, 2018 7:01 AM
To: He, Roger <hongbo...@amd.com>
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Ma, Le <le...@amd.com>;
Koenig, Christian <christian.koe...@amd.com>
Subject: [radeon-alex:amd-staging-dkms-4.13 3272/3830]
drivers/staging//vb
, allow TTM
allocation.
v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
Signed-off-by: Roger He <hongbo...@amd.com>
---
Because ttm_bo_force_list_clean() is only called on two occasions:
1. By ttm_bo_evict_mm() during suspend.
2. By ttm_bo_clean_mm() when the driver unloads.
On both cases we absolutely don't want any memory allocation failure.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/d
, it will trigger OOM killer.
will be used later.
v2: set the FORCE_ALLOC always
v3: minor refine
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
include/drm/ttm/ttm_bo_api.h| 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/g
Ok. please ignore patch3 since I have some minor changes.
Will send out later.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Koenig, Christian
Sent: Friday, February 09, 2018 5:38 PM
To: He, Roger <hongbo...@amd.com>; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] d
, allow TTM
allocation.
v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as ttm_opt_ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC
Signed-off-by: Roger He <hongbo...@amd.com&
if it is true, allocate TTM pages regardless of zone global memory
account limit. For example suspend, We should avoid TTM memory
allocate failure to lead to whole process fail.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 -
1 file chan
, it will trigger OOM killer.
v2: keep original behavior except ttm bo with flag no_retry
v3: forward the ttm_operation_ctx to ttm_mem_global_reserve
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_memory.c
I can't think of an use case when we don't want this to succeed.
That is true. seems I can simplify more here.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Koenig, Christian
Sent: Thursday, February 08, 2018 8:58 PM
To: He, Roger <hongbo...@amd.com>
, it will trigger OOM killer.
the subsequent patche will use this.
v2: keep original behavior except ttm bo with flag no_retry
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 -
include/drm/ttm/ttm_bo
if true, allocate TTM pages regardless of zone global memory
account limit. For suspend, We should avoid TTM memory allocate
failure then result in suspend failure.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/
allocation.
v2: merge two memory limit(swap and system) into one
v3: keep original behavior except with ttm->page_flags
TTM_PAGE_FLAG_NO_RETRY
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memory.c | 34
drivers/gp
for saving memory and more bit flag can be used in future
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
include/drm/ttm/ttm_bo
Sure, will make it turn off as default and make the limit configurable.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, February 07, 2018 4:41 PM
To: He, Roger <hongbo...@amd.com>; Thomas Hellstro
ttm_bo_device to let driver set
according to its request.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Wednesday, February 07, 2018 2:43 PM
To: He, Roger <hongbo...@amd.com>; amd-...@lists.freedesktop.org;
dri
, because initially I also concern that but
no better way at that time.
Going to improve the patches. Thanks!
-Original Message-
From: Koenig, Christian
Sent: Tuesday, February 06, 2018 5:52 PM
To: He, Roger <hongbo...@amd.com>; amd-...@lists.freedesktop.org;
dri-devel@lists.freedeskt
if true for it, allocate TTM pages regardless of zone global memory
account limit.
that is for another special case: suspend.
doesn't care the zone global memory account limit for this case.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.
, it will trigger OOM killer.
v2: keep original behavior except ttm bo with flag no_retry
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_memory.c | 25 +
drivers/gpu/d
for saving memory and more bit flag can be used in future
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
include/drm/ttm/ttm_bo
set the no_retry flag in struct ttm_mem_global and init it
after ttm_mem_global_init
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +---
drivers/gpu/drm/ttm/ttm_memory.c| 3 +++
include/drm/ttm/ttm_memory.h| 3 +++
3
> 256MB and at that time free swap
space is under 256MB but available system mem > its
lower limit, allow TTM allocation;
b. if total swap space < 256 or no swap disk at all, check
the available system mem, if it is bigger than its
threshold, allow TTM allocation.
Signed-off-by:
(by defaut), keep the original behavior
no any change.
Roger He (5):
drm/ttm: check if the free swap space is under limit 256MB
drm/ttm: keep original behavior except with flag no_retry
drm/ttm: use bit flag to replace allow_reserved_eviction in
ttm_operation_ctx
drm/ttm: add bit flag
Patch1 & 2 & 4, Reviewed-by: Roger He <hongbo...@amd.com>
Patch 5: Acked-by: Roger He <hongbo...@amd.com>
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Saturday, February 03,
The subsystem chould check that, not the driver.
Commit log typo, should be "should" rather than " chould".
With that fix, this patch is Reviewed-by: Roger He <hongbo...@amd.com>
Thanks
Roger(Hongbo.He)
Signed-off-by: Christian König <christian.koe...@amd.com
st today.
Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
He, Roger
Sent: Friday, February 02, 2018 3:54 PM
To: Koenig, Christian <christian.koe...@amd.com>; Zhou, David(ChunMing)
<david1.z...@amd.com>; dri-
Need call si_swapinfo to fill those valules .
void si_swapinfo(struct sysinfo *val)
But that function is not exported as well.
Thanks
Roger(Hongbo.He)
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Chunming Zhou
Sent: Friday, February 02, 2018 3:38 PM
To: He
my machine, set it as 4G can work.
But 4G also not work on test machine with 16GB system memory & 8GB swap disk.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Koenig, Christian
Sent: Friday, February 02, 2018 3:46 PM
To: He, Roger <hongbo...@amd.com>; Zhou, David(ChunMi
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memory.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 875e5b8..25e1ce0 100644
--- a/drivers/gpu/drm/ttm/ttm_me
because this zone has only 4GB, it is easy to became bottleneck for
huge normal zone.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +++
drivers/gpu/drm/ttm/ttm_memory.c| 10 --
include/drm/ttm/ttm_memory.h| 1 +
3
OOM killer.
v2: fix minor typo
v3: keep original behavior except ttm page with flag NO_RETRY
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +-
drivers/gpu/drm/ttm/ttm_memory.c | 27 +++
drivers/gpu/d
ory which can't be flushed into swap space.
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memory.c | 12
drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
include/drm/ttm/ttm_memory.h | 2 ++
3 files changed, 21 insertions(+), 6 deletions(-)
d
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files changed, 10 insertions
is bigger than swap disk, so no swap for TTM is allowed
at all.
For now we work out an improved version based on get_nr_swap_pages().
Going to send out later.
Thanks
Roger(Hongbo.He)
-Original Message-
From: He, Roger
Sent: Thursday, February 01, 2018 4:03 PM
To: Koenig, Christian <christian.
more swap space as well.
Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
He, Roger
Sent: Thursday, February 01, 2018 1:48 PM
To: Koenig, Christian <christian.koe...@amd.com>; Zhou, David(ChunMing)
<
Hi Michal:
How about only
EXPORT_SYMBOL_GPL(total_swap_pages) ?
Thanks
Roger(Hongbo.He)
-Original Message-
From: He, Roger
Sent: Wednesday, January 31, 2018 1:52 PM
To: 'Michal Hocko' <mho...@kernel.org>; Koenig, Christian
<christian.koe...@amd.com>
Cc: linux...@kvack.or
.
For example: total system memory * 1/2.
If that it will match the platform configuration better.
Roger can you test that approach once more with your fix for the OOM
issues in the page fault handler?
Sure. Use the limit as total ram*1/2 seems work very well.
No OOM although swap disk
I think this patch isn't need at all. You can directly read
total_swap_pages variable in TTM.
Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using will
result in:
"WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!".
Th
isk at all. Only special test case use more or probably that is
intentional.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Michal Hocko [mailto:mho...@kernel.org]
Sent: Tuesday, January 30, 2018 8:29 PM
To: Koenig, Christian <christian.koe...@amd.com>
Cc: He, Roger <hongbo
wap size and control
the swap size used by TTM very accurately.
Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
He, Roger
Sent: Tuesday, January 30, 2018 10:57 AM
To: Michal Hocko <mho...@kernel.org>
Cc: lin
.
But get_nr_swap_pages is the only API we can accessed from other module now.
It can't cover the case of the dynamic swap size increment.
I mean: user can use "swapon" to enable new swap file or swap disk dynamically
or "swapoff" to disable swap space.
Thanks
Roger(Hongb
, it will trigger OOM killer.
v2: add new page flag TTM_PAGE_FLAG_PAGEFAULT rather than using
struct ttm_operation_ctx
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
drivers/gpu/drm/ttm/ttm_memory.c | 27 +++
drivers/g
ory which can't be flushed into disk/file. At this time, any
memory request will trigger OOM killer.
v2: always get total system swap size rather than getting it once
at module init time
Signed-off-by: Roger He <hongbo...@amd.com>
---
drivers/gpu/drm/ttm/ttm_memo
1 - 100 of 196 matches
Mail list logo
