[算子开发][内测体验][AscendC] VF内printf ub溢出风险，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，影响算子正常逻辑-asc-devkit-AtomGit

已关闭

[算子开发][内测体验][AscendC] VF内printf ub溢出风险，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，影响算子正常逻辑 #1448

李鑫创建于 8月6日关闭于 27 天前

8月6日创建

https://gitcode.com/cann/asc-devkit/blob/master/docs/zh/api/Utils-API/tuning_interface/printf.md

该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，算子按照getubsize接口获取的ub进行执行时，可能ub溢出。使得开发为了使用该接口可能得额外修改tiling，资料中也未提示该风险

__simd_vf__ inline void SimdVfPrint()
{
    __ubuf__ const char* fmt = "simd vf: int=%d, uint=%u, float=%f, string=%s\n";
    printf(fmt, 1, 2U, 5.0f, "AscendC");
}

李鑫

8月6日修改标题为 “[算子开发][内测体验][AscendC] VF内printf ub溢出风向，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，影响算子正常逻辑”，原标题为“[算子开发][内测体验][AscendC] VF内printf易用性问题，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小”

李鑫

8月6日修改标题为 “[算子开发][内测体验][AscendC] VF内printf ub溢出风险，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，影响算子正常逻辑”，原标题为“[算子开发][内测体验][AscendC] VF内printf ub溢出风向，该接口需要定义ubuf的字符串字符串会占用静态内存，导致实际可用的ub变小，影响算子正常逻辑”

C ChenZhoujie成员

8月7日将 ChenZhoujie 设为负责人

ChenZhoujie成员

8月7日评论：

从语义上，定义的字符串为__ubuf__ const char*，能够较为明显地看出使用静态内存空间。
getubsize这个接口具体是指哪个？该接口如果获取的是整个UB的大小那么结果也是准确的。

李鑫

8月7日评论：

从语义上，定义的字符串为__ubuf__ const char*，能够较为明显地看出使用静态内存空间。
getubsize这个接口具体是指哪个？该接口如果获取的是整个UB的大小那么结果也是准确的。

@ChenZhoujie

ascendcPlatform.GetCoreMemSize(platform_ascendc::CoreMemType::UB, ubSizePlatform)这个接口。问题在于这个接口获取的是248K，意味着算子逻辑正常场景下就会使用248K进行计算。现在静态ub额外占用了部分，就可能导致预留的8k+248k+静态ub超过256K吧

ChenZhoujie成员

8月8日评论：

@lixin433
GetCoreMemSize得到的是单个 Vector Core 上可用于规划的UB容量，不是当前 Kernel 的实时剩余空间。
“就可能导致预留的8k+248k+静态ub超过256K吧”，248k得到的就是UB容量，静态ub只是这段ub空间的头部部分，并不存在相加的情况。
使用框架侧提供的接口时，会自动从静态空间末尾开始分配Tensor等内存。

李鑫

8月8日评论：

@lixin433
GetCoreMemSize得到的是单个 Vector Core 上可用于规划的UB容量，不是当前 Kernel 的实时剩余空间。
“就可能导致预留的8k+248k+静态ub超过256K吧”，248k得到的就是UB容量，静态ub只是这段ub空间的头部部分，并不存在相加的情况。
使用框架侧提供的接口时，会自动从静态空间末尾开始分配Tensor等内存。

@ChenZhoujie

这就是问题了。静态ub占用了248k中的部分，算子实际可用的ub小于248k，但是还是按248k的逻辑执行的，就会出问题。直白点，算子tiling阶段是感知不到这部分静态ub，因此建议这部分ub使用框架预留的8kb，不要侵入算子的业务ub，否则要么ub越界功能异常，要么为了使用这个调测接口而修改tiling，导致调测阶段和业务实际运行时由于可用ub不同而行为不一致的问题。

李鑫

8月11日 issue类型由任务改变为缺陷

ChenZhoujie成员

8月11日评论：

@lixin433
GetCoreMemSize得到的是单个 Vector Core 上可用于规划的UB容量，不是当前 Kernel 的实时剩余空间。
“就可能导致预留的8k+248k+静态ub超过256K吧”，248k得到的就是UB容量，静态ub只是这段ub空间的头部部分，并不存在相加的情况。
使用框架侧提供的接口时，会自动从静态空间末尾开始分配Tensor等内存。

@ChenZhoujie

这就是问题了。静态ub占用了248k中的部分，算子实际可用的ub小于248k，但是还是按248k的逻辑执行的，就会出问题。直白点，算子tiling阶段是感知不到这部分静态ub，因此建议这部分ub使用框架预留的8kb，不要侵入算子的业务ub，否则要么ub越界功能异常，要么为了使用这个调测接口而修改tiling，导致调测阶段和业务实际运行时由于可用ub不同而行为不一致的问题。

@lixin433

tiling阶段是无法感知device侧的静态内存分配情况。这部分当前编译器的逻辑是会将字符串放在静态空间位置，预留的8KB现在由于有编译选项可以全部或者部分关闭，不能简单地使用预留8KB，内存转移到8KB中还需要和编译器以及SE沟通协商。

ChenZhoujie成员

8月27日评论：

SE当前方案会将这部分字符串放入gm当中，然后通过调测接口如printf作为入口进行字符串的拼接处理，后续由正式需求跟踪

C ChenZhoujie成员

27 天前 issue状态由待办的改变为已解决

C ChenZhoujie成员

27 天前关闭了 issue