On 3/22/2024 11:29 AM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Rajneesh Bhardwaj
Sent: Friday, March 22, 2024 3:08 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: felix.kuehl...@amd.com; alexander.deuc...@amd.com;
On 3/22/2024 9:15 AM, Christian König wrote:
Am 22.03.24 um 08:07 schrieb Rajneesh Bhardwaj:
This change allows TTM to be flexible to honor NUMA localized
allocations which can result in significant performance improvement on a
multi socket NUMA system. On GFXIP 9.4.3 based AMD APUs, we see
[AMD Official Use Only - General]
-Original Message-
From: Steven Rostedt
Sent: Monday, January 22, 2024 6:19 PM
To: LKML
Cc: Linus Torvalds ; Bhardwaj, Rajneesh
; Kuehling, Felix ; Koenig,
Christian ; dri-devel@lists.freedesktop.org
Subject: Re: [BUG] BUG: kernel NULL pointer
On 1/22/2024 7:43 PM, Linus Torvalds wrote:
On Mon, 22 Jan 2024 at 15:17, Steven Rostedt wrote:
Perhaps this is the real fix?
If you send a signed-off version, I'll apply it asap.
I think a fix might already be in flight. Please see Linux-Kernel
Archive: Re: [PATCH] drm/ttm: fix ttm pool
On 1/22/2024 7:34 PM, Steven Rostedt wrote:
On Mon, 22 Jan 2024 19:29:41 -0500
"Bhardwaj, Rajneesh" wrote:
In one of my previous revisions of this patch when I was experimenting,
I used something like below. Wonder if that could work in your case
and/or in general.
diff --git
On 1/22/2024 6:06 PM, Steven Rostedt wrote:
I just kicked off testing some patches on top of 6.8-rc1 and triggered this
immediately:
[ note this happened on both my 32 bit an 64 bit test machines, this is
just the 32 bit output ]
BUG: kernel NULL pointer dereference, address: 0238
[AMD Official Use Only - General]
-Original Message-
From: amd-gfx On Behalf Of Hamza Mahfooz
Sent: Monday, November 27, 2023 10:53 AM
To: Christian König ;
jani.nik...@linux.intel.com; kher...@redhat.com; d...@redhat.com;
za...@vmware.com; Olsak, Marek ;
On 11/8/2023 9:49 AM, Christian König wrote:
Am 08.11.23 um 13:58 schrieb Rajneesh Bhardwaj:
Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.
To optimize the memory clearing operation when a TTM BO
[AMD Official Use Only]
Please ignore the previous email, that was sent in error. This one is with the
minor version bump so this looks good.
Reviewed-by : Rajneesh Bhardwaj
-Original Message-
From: amd-gfx On Behalf Of David Yat Sin
Sent: Tuesday, March 8, 2022 4:08 PM
To:
[AMD Official Use Only]
Reviewed-by: Rajneesh Bhardwaj
-Original Message-
From: amd-gfx On Behalf Of David Yat Sin
Sent: Tuesday, March 8, 2022 2:12 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Kuehling, Felix ; Yat Sin, David
Subject: [PATCH] drm/amdkfd:
[AMD Official Use Only]
Thank you Felix for the review and your guidance.
-Original Message-
From: Kuehling, Felix
Sent: Thursday, February 3, 2022 10:22 PM
To: Bhardwaj, Rajneesh ;
amd-...@lists.freedesktop.org
Cc: Yat Sin, David ; Deucher, Alexander
; dri-devel
20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
[SNIP]
Still sounds funky. I think minimally we should have an ack from CRIU
developers that this is officially the right way to solve this
problem. I
really don't want to have random one-off hacks that don't work across
the
board
Sorry for the typo in my previous email. Please read Adrian Reber*
On 12/22/2021 8:49 PM, Bhardwaj, Rajneesh wrote:
Adding Adrian Rebel who is the CRIU maintainer and CRIU list
On 12/22/2021 3:53 PM, Daniel Vetter wrote:
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote
Adding Adrian Rebel who is the CRIU maintainer and CRIU list
On 12/22/2021 3:53 PM, Daniel Vetter wrote:
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
On 12/20/2021 4:29 AM, Daniel Vetter wrote:
On Fri, Dec 10, 2021 at 07:58:50AM +0100, Christian König wrote:
Am
,
Rajneesh
Regards,
Christian.
Regards,
Felix
Regards,
Christian.
Am 09.12.21 um 16:29 schrieb Bhardwaj, Rajneesh:
Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank
you!
On 12/9/2021 10:27 AM, Christian König wrote:
Hi Rajneesh,
yes, separating this from
restrictions applied
exactly that is not correct. That behavior is actively used by some
userspace stacks as far as I know.
Regards,
Christian.
Am 09.12.21 um 16:23 schrieb Bhardwaj, Rajneesh:
Thanks Christian. Would it make it less intrusive if I just use the
flag for ttm bo mmap and remove
Thanks Christian. Would it make it less intrusive if I just use the flag
for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch?
For our use case, just the ttm_bo_mmap_obj change should suffice and we
don't want to put any more work arounds in the user space (thunk, in our
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Rajneesh Bhardwaj
-Original Message-
From: amd-gfx On Behalf Of Oak Zeng
Sent: Wednesday, March 10, 2021 10:29 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Zeng, Oak
Subject: [PATCH 2/2]
On 3/4/2021 12:31 PM, Christian König wrote:
[CAUTION: External Email]
Am 04.03.21 um 18:01 schrieb Bhardwaj, Rajneesh:
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache
I was wondering if a managed version of such API exists but looks like
none. We only have devm_ioremap_wc but that is valid only for
PAGE_CACHE_MODE_WC whereas ioremap_cache uses _WB. One more small
comment below.
Acked-by: Rajneesh Bhardwaj
On 3/4/2021 11:04 AM, Oak Zeng wrote:
If
20 matches
Mail list logo
