Re: [PATCH v2 0/2] Fix a bunch of allmodconfig errors
On Fri, 25 Nov 2022, Andrew Morton wrote:
> On Fri, 25 Nov 2022 12:07:48 + Lee Jones wrote:
>
> > Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST")
> > WERROR
> > now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
> >
> > builds. This leads to some interesting failures, each resolved in this
> > set.
>
> I'm not sure who this patchset is aimed at, so I'll take my usual
> approach of grabbing it and seeing who complains.
>
> > With this set applied, I am able to obtain a successful allmodconfig Arm
> > build.
>
> b339ec9c229aa is a year old and I've been doing arm allmodconfig for
> ever. What am I missing here?
>
> A broken arm allmodconfig is pretty irritating - I'm thinking that a
> fix should be backported into -stable kernels. But I'm clearly missing
> something here.
I will be taking these through all applicable Stable kernels.
--
Lee Jones [李琼斯]
[PATCH v3] drm: Optimise for continuous memory allocation
Currently drm-buddy does not have full knowledge of continuous memory.
Lets consider scenario below.
order 1:L R
order 0: LL LR RL RR
for order 1 allocation, it can offer L or R or LR+RL.
For now, we only implement L or R case for continuous memory allocation.
So this patch aims to implement the LR+RL case.
Signed-off-by: xinhui pan
---
change from v2:
search continuous block in nearby root if needed
change from v1:
implement top-down continuous allocation
---
drivers/gpu/drm/drm_buddy.c | 78 +
1 file changed, 71 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..ff58eb3136d2 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -386,6 +386,58 @@ alloc_range_bias(struct drm_buddy *mm,
return ERR_PTR(err);
}
+static struct drm_buddy_block *
+find_continuous_blocks(struct drm_buddy *mm,
+ int order,
+ unsigned long flags,
+ struct drm_buddy_block **rn)
+{
+ struct list_head *head = &mm->free_list[order];
+ struct drm_buddy_block *node, *parent, *free_node, *max_node = NULL;
+ int i;
+
+ list_for_each_entry(free_node, head, link) {
+ if (max_node) {
+ if (!(flags & DRM_BUDDY_TOPDOWN_ALLOCATION))
+ break;
+
+ if (drm_buddy_block_offset(free_node) <
+ drm_buddy_block_offset(max_node))
+ continue;
+ }
+
+ parent = free_node;
+ do {
+ node = parent;
+ parent = parent->parent;
+ } while (parent && parent->right == node);
+
+ if (!parent) {
+ for (i = 0; i < mm->n_roots - 1; i++)
+ if (mm->roots[i] == node)
+ break;
+ if (i == mm->n_roots - 1)
+ continue;
+ node = mm->roots[i + 1];
+ } else {
+ node = parent->right;
+ }
+
+ while (drm_buddy_block_is_split(node))
+ node = node->left;
+
+ if (drm_buddy_block_is_free(node) &&
+ drm_buddy_block_order(node) == order) {
+ *rn = node;
+ max_node = free_node;
+ BUG_ON(drm_buddy_block_offset(node) !=
+ drm_buddy_block_offset(max_node) +
+ drm_buddy_block_size(mm, max_node));
+ }
+ }
+ return max_node;
+}
+
static struct drm_buddy_block *
get_maxblock(struct list_head *head)
{
@@ -637,7 +689,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
struct list_head *blocks,
unsigned long flags)
{
- struct drm_buddy_block *block = NULL;
+ struct drm_buddy_block *block = NULL, *rblock = NULL;
unsigned int min_order, order;
unsigned long pages;
LIST_HEAD(allocated);
@@ -689,17 +741,29 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
break;
if (order-- == min_order) {
+ if (!(flags & DRM_BUDDY_RANGE_ALLOCATION) &&
+ min_order != 0 && pages == BIT(order + 1)) {
+ block = find_continuous_blocks(mm,
+ order,
+ flags,
+ &rblock);
+ if (block)
+ break;
+ }
err = -ENOSPC;
goto err_free;
}
} while (1);
- mark_allocated(block);
- mm->avail -= drm_buddy_block_size(mm, block);
- kmemleak_update_trace(block);
- list_add_tail(&block->link, &allocated);
-
- pages -= BIT(order);
+ do {
+ mark_allocated(block);
+ mm->avail -= drm_buddy_block_size(mm, block);
+ kmemleak_update_trace(block);
+ list_add_tail(&block->link, &allocated);
+ pages -= BIT(order);
+ block = rblock;
+ rblock = NULL;
+ } while (block);
if (!pages)
break;
--
2.34.1
Re: [PATCH 1/9] drm/amdgpu: generally allow over-commit during BO allocation
Hi Christian,
Looks good to me.
Reviewed-by: Arunpravin Paneer Selvam
for the series.
Regards,
Arun.
On 11/25/2022 3:51 PM, Christian König wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to allocate/free
GTT in a loop and are otherwise only limited by the CPU speed.
The CS will wait for the cleanup of freed up BOs to satisfy the
various domain specific limits and so effectively throttle those
buggy applications down to a sane allocation behavior again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 16 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a0780a4e3e61..62e98f1ad770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -113,7 +113,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev,
unsigned long size,
bp.resv = resv;
bp.preferred_domain = initial_domain;
bp.flags = flags;
- bp.domain = initial_domain;
+ bp.domain = initial_domain | AMDGPU_GEM_DOMAIN_CPU;
bp.bo_ptr_size = sizeof(struct amdgpu_bo);
r = amdgpu_bo_create_user(adev, &bp, &ubo);
@@ -332,20 +332,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void
*data,
}
initial_domain = (u32)(0x & args->in.domains);
-retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
-initial_domain,
-flags, ttm_bo_type_device, resv, &gobj);
+initial_domain, flags, ttm_bo_type_device,
+resv, &gobj);
if (r && r != -ERESTARTSYS) {
- if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
- flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
- goto retry;
- }
-
- if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
- initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
- goto retry;
- }
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu,
%d)\n",
size, initial_domain, args->in.alignment, r);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..919bbea2e3ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -581,11 +581,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
bo->tbo.bdev = &adev->mman.bdev;
- if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
- AMDGPU_GEM_DOMAIN_GDS))
- amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
- else
- amdgpu_bo_placement_from_domain(bo, bp->domain);
+ amdgpu_bo_placement_from_domain(bo, bp->domain);
if (bp->type == ttm_bo_type_kernel)
bo->tbo.priority = 1;
Re: [PATCH v2 2/2] Kconfig.debug: Provide a little extra FRAME_WARN leeway when KASAN is enabled
On Fri, Nov 25, 2022 at 12:07:50PM +, Lee Jones wrote: > When enabled, KASAN enlarges function's stack-frames. Pushing quite a > few over the current threshold. This can mainly be seen on 32-bit > architectures where the present limit (when !GCC) is a lowly > 1024-Bytes. > > Signed-off-by: Lee Jones Reviewed-by: Nathan Chancellor > --- > lib/Kconfig.debug | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index c3c0b077ade33..82d475168db95 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -399,6 +399,7 @@ config FRAME_WARN > default 2048 if GCC_PLUGIN_LATENT_ENTROPY > default 2048 if PARISC > default 1536 if (!64BIT && XTENSA) > + default 1280 if KASAN && !64BIT > default 1024 if !64BIT > default 2048 if 64BIT > help > -- > 2.38.1.584.g0f3c55d4c2-goog >
Re: [PATCH v2 1/2] drm/amdgpu: Temporarily disable broken Clang builds due to blown stack-frame
On Fri, Nov 25, 2022 at 12:07:49PM +, Lee Jones wrote: > calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64) > architectures built with Clang (all released versions), whereby the stack > frame gets blown up to well over 5k. This would cause an immediate kernel > panic on most architectures. We'll revert this when the following bug report > has been resolved: https://github.com/llvm/llvm-project/issues/41896. > > Suggested-by: Arnd Bergmann > Signed-off-by: Lee Jones Reviewed-by: Nathan Chancellor > --- > drivers/gpu/drm/amd/display/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/Kconfig > b/drivers/gpu/drm/amd/display/Kconfig > index 6925e0280dbe6..f4f3d2665a6b2 100644 > --- a/drivers/gpu/drm/amd/display/Kconfig > +++ b/drivers/gpu/drm/amd/display/Kconfig > @@ -5,6 +5,7 @@ menu "Display Engine Configuration" > config DRM_AMD_DC > bool "AMD DC - Enable new display engine" > default y > + depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64 > select SND_HDA_COMPONENT if SND_HDA_CORE > select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128) > help > @@ -12,6 +13,12 @@ config DRM_AMD_DC > support for AMDGPU. This adds required support for Vega and > Raven ASICs. > > + calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 > || ARM64) > + architectures built with Clang (all released versions), whereby the > stack > + frame gets blown up to well over 5k. This would cause an immediate > kernel > + panic on most architectures. We'll revert this when the following > bug report > + has been resolved: https://github.com/llvm/llvm-project/issues/41896. > + > config DRM_AMD_DC_DCN > def_bool n > help > -- > 2.38.1.584.g0f3c55d4c2-goog >
