On 5/15/25 4:55 AM, Christian König wrote:
On 5/15/25 05:02, Dave Airlie wrote:
I have to admit I'm pretty clueless about the gpu driver internals and
can't really judge how feasible this is. But from a cgroup POV, if you
want proper memory isolation between groups, it seems to me that's the
dir
On 5/13/25 6:06 AM, Byungchul Park wrote:
llist_head and llist_node can be used by very primitives. For example,
I suppose you mean "every primitives". Right? However, the term
"primitive" may sound strange. Maybe just saying that it is used by some
other header files.
Cheers,
Longman
dep
On 5/1/25 11:36 PM, Dave Airlie wrote:
From: Dave Airlie
This adds the memcg object for any user allocated object,
and adds account_op to necessary paths which might populate
a tt object.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 ++-
drivers/gpu/dr
On 1/14/25 1:28 AM, Jiapeng Chong wrote:
Variable climit is not effectively used, so delete it.
kernel/cgroup/dmem.c:302:23: warning: variable ‘climit’ set but not used.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=13512
Signed-off-by: Jiapeng Chong
---
ke
On 10/23/24 3:52 AM, Maarten Lankhorst wrote:
The initial version was based roughly on the rdma and misc cgroup
controllers, with a lot of the accounting code borrowed from rdma.
The current version is a complete rewrite with page counter; it uses
the same min/low/max semantics as the memory cgr
On 1/17/23 13:18, Boqun Feng wrote:
[Cc Waiman]
On Mon, Jan 16, 2023 at 10:00:52AM -0800, Linus Torvalds wrote:
[ Back from travel, so trying to make sense of this series.. ]
On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park wrote:
I've been developing a tool for detecting deadlock possibilities
On 1/3/23 10:39, Felix Kuehling wrote:
The regression point doesn't make sense. The kernel config doesn't
enable CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU
could have caused this regression.
I agree. It is likely a pre-existing problem or caused by another commit
that got t
ries looks good to me.
Acked-by: Waiman Long
Thanks!
On 12/06/2016 01:29 PM, Peter Zijlstra wrote:
> On Tue, Dec 06, 2016 at 11:03:28AM -0500, Waiman Long wrote:
>> The mutex_spin_on_owner() function was originally marked noinline
>> because it could be a major consumer of CPU cycles in a contended lock.
>> Having it shown s
On 12/06/2016 10:06 AM, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
>> +++ b/kernel/locking/mutex.c
>> @@ -350,7 +350,8 @@ ww_mutex_set_context_slowpath(struct ww_mutex *lock,
>> * access and not reliable.
>> */
>> static noinline
>> -bool mutex_spi
10 matches
Mail list logo
