From a232b2bf470c64029ce99a9f3d5b0ec01f2490b9 Mon Sep 17 00:00:00 2001 From: Eli Ma Date: Thu, 28 May 2020 23:41:37 +0800 Subject: [PATCH] Update the Summer 2020 tasks until No.100 Signed-off-by: Eli Ma --- events/summer2020/tasks.md | 600 ++++++++++++++++++++++++++++++++++++- 1 file changed, 594 insertions(+), 6 deletions(-) diff --git a/events/summer2020/tasks.md b/events/summer2020/tasks.md index 1980838..5d4ff79 100644 --- a/events/summer2020/tasks.md +++ b/events/summer2020/tasks.md @@ -1074,15 +1074,12 @@ windows下everything工具是非常好用的文件快速检索软件，但是在 P.S. 实现方式可以基于命令行或图形界面 _难度_ - -中等-困难 +中 _导师_ - @denggx_elros _联系方式_ - dengguangxing@huawei.com _任务链接_ https://gitee.com/openeuler/marketing/issues/I1IELF @@ -1198,7 +1195,7 @@ _联系方式_ pannengyuan@huawei.com _任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHCJ -#### [No.67 - 基于需求覆盖度判断的用例筛选方法（RBC，requirement-based coverage）探索及工程构建]()(https://gitee.com/openeuler/marketing/issues/I1IHGJ) +#### [No.67 - 基于需求覆盖度判断的用例筛选方法（RBC，requirement-based coverage）探索及工程构建](https://gitee.com/openeuler/marketing/issues/I1IHGJ) _描述_ OS内核及基础包众多，在代码迭代过程中，都需要执行大量自动化用例来保证修改的代码不会影响模块的原有功能。但是，现在的用例集和用例级别划分不是很明确，每次执行的用例有很多是冗余的。 @@ -1231,4 +1228,595 @@ hw_niubility _联系方式_ hw_niubility@yeah.net -_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHIT \ No newline at end of file +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHIT + +#### [No.69 - api-sanity-checker 与 oss-fuzz 测试结合的误报优化](https://gitee.com/openeuler/marketing/issues/I1IHNM) + +_描述_ +api-sanity-checker是一款基于c/c++ 库文件和头文件信息，为头文件中声明的每一个对外接口自动生成用例，然后进行编译，运行的开源工具。 +oss-fuzz是google开发的一个开源软件fuzz测试自动化平台，使用clusterfuzz作为后台，利用容器快速构建环境，同时集成了ASAN/MSAN/UBSAN等故障检测工具。 +当前，我们将这两个工具进行结合，即改造api-sanity-checker工具，使其为满足一定条件的接口自动生成fuzz用例，然后使用oss-fuzz进行编译、执行用例。但当前初步实践后，进行失败用例分析时，发现很多都是误报，非代码bug，故需要进行优化，自动过滤掉误报，使报错率更准确，提高测试效率。 + +_难度_ +高 + +_导师_ +yanjineuler + +_联系方式_ +jiqin.ji@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHNM + +#### [No.70 - openEuler 源码包成分提取、归档](https://gitee.com/openeuler/marketing/issues/I1IHUT) + +_描述_ linux操作系统由众多开源软件包组成，需要获取 openEuler 操作系统源码包信息 包括：软件包范围、包版本、源码包拆分为二进制包信息，二进制包的内容文件信息，并将获取信息格式化输入到数据库)。 + +_难度_ 中 + +_导师_ @jimmy_hero + +_联系方式_ huming15@163.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHUT + +#### [No.71 - openEuler 不同系统间源码包成分信息比较](https://gitee.com/openeuler/marketing/issues/I1IHVG) + +_描述_ linux操作系统由众多开源软件包组成，需要根据不同openEuler操作系统源码包信息尽心比较， 包括：软件包范围、包版本、源码包拆分为二进制包信息，二进制包的内容文件信息，比较源码包信息的一致性。 + +_难度_ 低 + +_导师_ @jimmy_hero + +_联系方式_ huming15@163.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IHVG + +#### [No.72 - 针对Go加解密库进行ARM64相关的优化](https://gitee.com/openeuler/marketing/issues/I1IIW6) + +_描述_ +- Go加解密（crypto）库中包含着通用的对称、非对称加密算法，通过SIMD、CPU流水线、缓存命中等进行汇编，提升Go语言该包的性能优化 + +_难度_ +- 中 + +_导师_ +- [@mabingo](https://gitee.com/mabingo) + +_联系方式_ +- mabin@apache.org + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IIW6 + +#### [No.73 - 增强Golang运行时库在ARM上的性能和安全性](https://gitee.com/openeuler/marketing/issues/I1IJ0J) + +_描述_ +- Golang运行时库(runtime)包含go语言运行的基础设施，负责管理协程调度、垃圾回收、内存分配、与操作系统交互等。是go语言的核心模块。本项目的目标是结合基本的Linux操作系统和ARM64体系结构、汇编知识，优化Golang运行时库在ARM64服务器的表现，提高部分运行时库函数的性能或安全性，通过深度参与社区了解SIMD、CPU Cache、流水线调优、SSA编译规则调优等技术的原理和具体使用，成长为开源贡献者。 + +_难度_ +- 高 + +_导师_ +- [@mabingo](https://gitee.com/mabingo) +- [@surechen](https://gitee.com/surechen) + +_联系方式_ +- mabin@apache.org +- 814464284@qq.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ0J + +#### [No.74 - 优化Golang图像库功能和性能](https://gitee.com/openeuler/marketing/issues/I1IJ24) + +_描述_ +- Golang图像库是一个基本的二维图像库，支持gif、jpeg、png等格式。 +本项目的目标是优化图像库在ARM64服务器的表现，包括性能、安全性、空间占用、代码可读性等方面，通过本项目熟悉SIMD、CPU Cache、指令和寄存器选择、流水线调优等技术。 + +_难度_ +- 中 + +_导师_ +- @surechen + +_联系方式_ +- 814464284@qq.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ24 + +#### [No.75 - Numpy 在 ARM 平台的优化](https://gitee.com/openeuler/marketing/issues/I1IJ3H) + +_描述_ +NumPy是一个高性能的Python数学库，支持大量的维度数组与矩阵运算，广泛应用在信号处理、图像处理和AI领域，但目前社区主要针对X86平台提供了SIMD优化，ARM平台的优化工作才刚刚起步，需要采用ARM特有的Neon指令集，尽可能的提高数学运算的性能。 + +_难度_ +中 + +_导师_ +@iotwins + +_联系方式_ +fangchunlin@huawei.com +834352945@qq.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ3H + +#### [No.76 - 优化golang压缩库的压缩率或压缩性能](https://gitee.com/openeuler/marketing/issues/I1IJ4M) + +_描述_ +- 目前的golang压缩库中有包括bzip2、zlib、flate、gzip等多种压缩算法，要求结合ARM硬件架构的特征，采用并行计算、汇编等方法实现压缩库中的至少2种算法在ARM平台上的优化，将压缩率或压缩速度尽可能提高。 + +_难度_ +- 中 + +_导师_ +- @Heisenberg_li + +_联系方式_ +- lziqiang1@gmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ4M + +#### [No.77 - 在Eigen社区中提供ARM的CI环境](https://gitee.com/openeuler/marketing/issues/I1IJ4N) + +_描述_ +Eigen是一个基础数学库开源项目，当前基于不同的架构进行了大量优化，需要提供基于ARM的CI环境，以简化开源开发工作。 + +_难度_ +中 + +_导师_ +陈衎 + +_联系方式_ +chenkan5@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ4N + +#### [No.78 - 基于ARM的硬件加速能力软硬件协同调优go数学库函数](https://gitee.com/openeuler/marketing/issues/I1IJ4X) + +_描述_ +- 灵活运用ARM64汇编优化、SIMD指令优化、算法改进等软硬协同调优方法，提升go数学库函数在ARM64硬件上的性能。 + +_难度_ + +- 中 + +_导师_ + +- 周中元 + +_联系方式_ + +- zhouzhongyuan96@gmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ4X + +#### [No.79 - Golang 编解码算法性能优化](https://gitee.com/openeuler/marketing/issues/I1IJ5T) + +_描述_ +- 在golang的编解码库中有多种算法，要求结合ARM硬件架构的特征，实现编解码至少2种算法在ARM平台上的优化，提高编解码算法的性能。 + +_难度_ +- 中 + +_导师_ +- @Heisenberg_li + +_联系方式_ +- lziqiang1@gmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ5T + +#### [No.80 - 增强 Golang 编译器基于ARM64的智能化编译](https://gitee.com/openeuler/marketing/issues/I1IJ5W) + +_描述_ + +- 增强Go原生编译器内架构相关的代码降级、转换、优化等处理过程，智能化提升基于ARM64硬件的Go编译能力，提高Go库函数在ARM64上的运行性能。 + +_难度_ + +- 高 + +_导师_ + +- 周中元 + +_联系方式_ + +- zhouzhongyuan96@gmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ5W + +#### [No.81 - 优化Go同步包中锁或原子操作在 ARM64 上的实现，提升安全并发的性能](https://gitee.com/openeuler/marketing/issues/I1IJ86) + +_描述_ +Go同步（sync）包中有三个关于安全并发的保障机制：原子操作（atomic.Value）、同步锁（sync.Mutex）、读写锁（sync.RWMutex）,通过逻辑或算法实现对其中一个或多个进行优化，提升性能 + +_难度_ +高 + +_导师_ +@chinx + +_联系方式_ +zhuchen@apache.org + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ86 + +#### [No.82 - 基于spdk的高性能用户态用户态文件系统](https://gitee.com/openeuler/marketing/issues/I1IKCX) + +_描述_ +基于spdk打造高性能用户态文件系统 + +- 文件系统的功能完善，功能对标ext4。 +- 高效：针对NVMe SSD设备设计高效的元数据管理，高效的cache机制，预读等能力 +- 可靠：数据一致性 +- 安全：具备访问权限能力 +- 性能相对内核态10倍提升（用户态FS+SPDK+用户态NVMe driver vs. 内核态FS+内核态block+内核态NVMe Driver） + +_难度_ +高 + +_导师_ +@yanxiaodan + +_联系方式_ +yanxiaodan@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IKCX + +#### [No.83 - 在Risc-V架构openEuler平台上提供golang支持](https://gitee.com/openeuler/marketing/issues/I1IKOI) + +_描述_ +Golang社区正在进行Risc-V架构的移植工作，并通过issue跟踪对应进展，目前已经能够完成构建，但还有部分特性待完成。跟踪并参与社区移植工作，在Risc-V架构的OpenEuler平台上完成golang工具包的构建，构建Risc-V golang生态。 + +_难度_ + +难 + +_导师_ + +@denggx_elros +@whoisxxx +@haomintsai + +_联系方式_ + +dengguangxing@huawei.com +zhangxuzhou4@huawei.com +caihaomin@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IKOI + +#### [No.84 - 在 RISC-V 架构 openEuler 平台上提供 iSulad](https://gitee.com/openeuler/marketing/issues/I1IKQO) + +_描述_ +iSulad是openEuler开源的容器管理工具，基于C语言开发；本任务希望能够在基于Risc-V架构的OpenEuler平台上实现iSulad工具支持，构建Risc-V架构openEuler容器生态基础。 + +_难度_ + +中等 + +_导师_ +- @denggx_elros +- @whoisxxx +- @haomintsai + + +_联系方式_ +- dengguangxing@huawei.com +- zhangxuzhou4@huawei.com +- caihaomin@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IKQO + +#### [No. 85 - 对openEuler社区发布包xz进行CRC加速](https://gitee.com/openeuler/marketing/issues/I1IKVH) + +_描述_ +xz使用了CRC32（多项式0xedb88320）来校验数据的正确性。软件使用了常用的查表法来做CRC计算，性能并不理想。在ARMv8.1，提供了CRC32/CRC32C的专用指令：crc32d, crc32w, crc32h, crc32b, crc32cd, crc32cw, crc32ch, crc32cb。分别实现64bit、32bit、16bit和8bit数据的CRC计算。 + +相对于查表法，ARM CRC指令快30倍左右。也就是说，对同一数据做CRC，加速指令耗用时间是查表法的1/30。 +对于CRC-32和CRC-32C，GCC提供了builtin函数，可以在C代码里直接调用。builtin函数名字就是对应的汇编指令名字前加“__”，比如__crc32d函数对应crc32d指令。另外，还需添加“-march=armv8.1-a”编译选项。 + +openEuler社区的xz发布包没有为ARM平台做过优化：https://gitee.com/src-openeuler/xz。 +本任务的目标就是为这个软件包在ARM上做加速，提高压缩性能。 + +_难度_ +中 + +_导师_ +[@colordev](https://gitee.com/colordev) + +_联系方式_ +colordev@hotmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IKVH + +#### [No.86 - 对openEuler社区发布包busybox进行CRC加速](https://gitee.com/openeuler/marketing/issues/I1IL9F) + +_描述_ +busybox使用了CRC32（多项式0xedb88320）来校验数据的正确性。软件使用了常用的查表法来做CRC计算，性能并不理想。在ARMv8.1，提供了CRC32/CRC32C的专用指令：crc32d, crc32w, crc32h, crc32b, crc32cd, crc32cw, crc32ch, crc32cb。分别实现64bit、32bit、16bit和8bit数据的CRC计算。 + +相对于查表法，ARM CRC指令快30倍左右。也就是说，对同一数据做CRC，加速指令耗用时间是查表法的1/30。 + +对于CRC-32和CRC-32C，GCC提供了builtin函数，可以在C代码里直接调用。builtin函数名字就是对应的汇编指令名字前加“__”，比如__crc32d函数对应crc32d指令。另外，还需添加“-march=armv8.1-a”编译选项。 + +openEuler社区的busybox发布包没有为ARM平台做过优化：https://gitee.com/src-openeuler/busybox。 +本任务的目标就是为这个软件包在ARM上做加速，提高压缩性能。 + +_难度_ +中 + +_导师_ +[@colordev](https://gitee.com/colordev) + +_联系方式_ +colordev@hotmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IL9F + +#### [no.87 - 基于Rust高性能HTTP库Hyper或Tide实现S3服务端](https://gitee.com/openeuler/marketing/issues/I1IMFO) + +_描述_ +Rust是性能非常好的系统语言，Rust社区已经提供了高性能的HTTP库Hyper和Tide,但是还没有基于Rust实现的高性能S3服务端。 + +由于S3协议是基于HTTP协议的，因此基于Rust的高性能的HTTP库Hyper或Tide，可以实现高性能S3服务端。 + +本任务要求用Rust异步编程框架，基于Hyper或Tide实现高性能S3服务端。 + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMFO + +#### [No.88 - 移植 openEuler 至 RK3399 平台](https://gitee.com/openeuler/marketing/issues/I1IJ4B) + +- openEuler 是一款开源操作系统。当前 openEuler 内核源于 Linux，支持鲲鹏及其它多种处理器，能够充分释放计算芯片的潜能，是由全球开源贡献者构建的高效、稳定、安全的开源操作系统。 +- RK3399 是瑞芯微推出的一款低功耗、高性能的应用处理器芯片。作为 Firefly 新一代的顶级开源平台，RK3399 凭借其高稳定性、高性能、高集成度、高扩展性而广泛用于人脸识别设备、无人机、机器人、游戏机等应用产品。 +- 本项目的目标是将 openEuler 移植到 Firefly-RK3399 上，并保证 RK3399 的外设均可用。 + +_难度_ 高 + +_导师_ +- overweight +- woqidaideshi + +_联系方式_ +- hexiaowen@huawei.com +- yafen@iscas.ac.cn + +_产出标准_ +- 1. openEuler 的 RK3399 的镜像 + - 内核基于 openEuler 20.03 LTS 版本的 Linux 内核 + - 文件系统基于 openEuler 20.03 LTS 软件源制作 + - 支持 AArch64 架构 + - 支持通过 dnf 安装 openEuler 20.03 LTS 软件源中的软件包 + - 支持编译 Linux 内核 + - RK3399 的硬件模块均可用，如 音频输入输出、USB 3.0、USB 2.0、以太网、Wifi、蓝牙、红外、摄像头、GPIO 等 +- 2. openEuler 内核适配到 RK3399 的内核源码补丁以及针对其他软件包的源码补丁 +- 3. 镜像制作程序和文档 +- 4. RK3399 的 音频输入输出、USB 3.0、USB 2.0、以太网、Wifi、蓝牙、红外、摄像头、GPIO 等的使用文档 + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IJ4B + +#### [No.89 - 基于Rust实现HDFS的用户态FUSE驱动](https://gitee.com/openeuler/marketing/issues/I1IMGW) + +_描述_ +HDFS是标准的大数据文件系统，但是访问HDFS需要使用专门的客户端程序。 +虽然已经有一些HDFS挂载到Linux的程序，但是访问性能不佳，没有得到普遍使用。 +Linux已经提供了用户态文件系统接口FUSE，用于给Linux挂载各种用户自定义的文件系统。 +本任务要求使用Rust实现基于FUSE的HDFS驱动，把HDFS通过FUSE挂载到Linux作为用户态的文件系统。 + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMGW + +#### [No.90 - 基于Perf或eBPF对FUSE进行tracing分析](https://gitee.com/openeuler/marketing/issues/I1IMIA) + +_描述_ +Perf和eBPF是Linux的tracing机制，用于分析应用程序的系统调用性能。 +FUSE是Linux的用户态文件系统接口，用于实现用户自定义的文件系统。 +目前FUSE缺乏对于系统调用的性能分析。本任务要求采用Perf或eBPF对FUSE做tracing，实现对FUSE的系统调用的深入性能分析。 + + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMIA + +#### [No.91 - 用RUST实现基于FUSE的Kubernetes CSI接口](https://gitee.com/openeuler/marketing/issues/I1IMJY) + +_描述_ + +- CSI是Kubernetes (K8S)的存储管理接口。FUSE是Linux的用户态文件系统接口。 +- 目前CSI还不能对接Linux下通过FUSE挂载的用户态文件系统。 +- 本任务要求用Rust实现CSI对接FUSE挂载的文件系统，实现对FUSE挂载的文件系统的管理。 + + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMJY + +#### [No.92 - 用Rust实现无锁LRU缓存](https://gitee.com/openeuler/marketing/issues/I1IMNR) + +_描述_ +Rust是一门高性能系统级语言。LRU缓存是底层系统经常用到的数据结构，出于性能的考虑LRU缓存不能加锁。本任务要求用Rust实现高性能的无锁LRU缓存。 + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMNR + +#### [No.93 - 用 Rust 实现无锁 HashMap](https://gitee.com/openeuler/marketing/issues/I1IMNX) + +_描述_ +Rust是一门高性能系统级语言。HashMap是经常用到的数据结构，在多线程并发情况下，出于性能的考虑要使用无锁HashMap。本任务要求用Rust实现高性能的无锁HashMap。 + +_难度_ +高 + +_导师_ +@pwang7 + +_联系方式_ +pwang7@foxmail.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMNX + +#### [No.94 - 实现API识别软件包依赖的功能](https://gitee.com/openeuler/marketing/issues/I1IMTI) + +_描述_ linux 软件之间采用模块化设计交付，各个软件之间独立安装及使用，为了方便接口的来源，需要直接根据软件模块的API 接口查询到属于哪个软件包，利于初学者对于软件 依赖模块的熟悉。 + +_难度_ 中 + +_导师_ @jimmy_hero + +_联系方式_ huming15@163.com + +_产出标准_ 在https://gitee.com/openeuler/oec-application 项目提交相关可以在基于如下环境运行的工具，根据二进制目标文件的外部引用API，获取API所在的软件包信息。 + +操作系统版本：openEuler 20.03 LTS +架构：aarch64 + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IMTI + +#### [No.95 - openEuler CPU故障隔离](https://gitee.com/openeuler/marketing/issues/I1INPO) + +_描述_ +操作系统可靠运行才能保证运行在其上的业务可靠运转，然而操作系统管理的硬件并不是可靠的，往往也会出现硬件错误。如内存会出现单bit位翻转或者多bit位翻转，当前的ECC内存可以对单bit翻转进行硬件纠错，保证数据的正确性，对于多Bit ECC错误则需要硬件与操作系统协同防止故障扩散。同样，系统中的其他硬件如CPU也会出现硬件故障，当CPU出现故障的时候，操作系统需要与硬件协同进行故障恢复以及故障隔离防止故障扩散，从而确保系统的可靠性。 + +_难度_ +中 + +_导师_ +- @lvying6 +- @Pces +- @licihua + +_联系方式_ +- lvying6@huawei.com +- chenjialong@huawei.com +- licihua@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1INPO + +#### [No.96 - 优化nfs-utils锁以解决并发性能差问题](https://gitee.com/openeuler/marketing/issues/I1INR1) + +_描述_ +NFS目前在共享存储中使用非常普遍，对客户端访问文件而言，NFS简单高效，NFS的缺点是IO性能较低。 +当前在性能测试和分析过程中，NFS的并发性能受限于NFS客户端锁机制，导致很多NFS请求出现较大的调度时延，在并发高时，时延达到几十秒，导致业务有异常。 +所以希望能够通过nfs客户端侧锁的优化来提高nfs客户端侧的并发能力。 + +_难度_ +高 + +_导师_ +@liuzhiqiang26 + +_联系方式_ +lzhq28@mail.ustc.edu.cn + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1INR1 + +#### [No.97 - 优化glibc内存管理框架内容空洞导致内存占用不断增加的问题](https://gitee.com/openeuler/marketing/issues/I1IO19) + +_描述_ +glibc 2.28以上版本的内存管理，是尝试从内核申请内存，自行管理，不直接释放给操作系统，在不断的申请释放过程中，由于不满足释放条件，会出现内存占用不断增加，无法释放的情况 + +_难度_ +高 + +_导师_ +刘思睿 + +_联系方式_ +liusirui@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IO19 + +#### [No.98 - 众核场景下OS基础设施机制线性度探索](https://gitee.com/openeuler/marketing/issues/I1IO7D) + +_描述_ +SMP多处理器架构的发展，核数的线性增长是多核性能提升的非充要条件。经过测试证明，在鲲鹏场景下随着核数增加，性能甚至会出现下降，例如当core增长到128->256 core时，性能下降明显，其中的关键瓶颈在于glibc提供的锁机制在众核竞争场景下性能劣化验证。解决该问题的一个方法是，拆锁减小临界区。但是有大量应用，例如mysql等代码规模大，历史时间长，面向处理器重构编程不太现实； + +提出一种新的方案或者优化机制，在上层应用无感知的情况下，屏蔽众核硬件差异，提供最佳的共享资源竞争策略 + +_导师_ + +- 吴旭 +- 李清清 + +_联系方式_ + +- wuxu.wu@huawei.com +- liqingqing3@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IO7D + + +#### [No.99 - MySQL 数据库性能线性度问题](https://gitee.com/openeuler/marketing/issues/I1IO9O) + +_描述_ +传统OLTP数据库已经被证明在100个CPU左右达到性能瓶颈; +研究软硬件结合的新一致性算法, 提升CPU拐点; + +_难度_ +高 + +_导师_ +@softkiller + +_联系方式_ +zhoukang7@huawei.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IO9O + +#### [No.100 - 将UKUI移植到openEuler，并支持生物识别](https://gitee.com/openeuler/marketing/issues/I1IRJ3) + +_描述_ UKUI是由麒麟团队打造的一款基于Qt的桌面环境，具有美观、简洁、易用的特点，生物识别是指通过计算机与光学、声学、生物传感器和生物统计学原理等高科技手段密切结合，利用人体固有的生理特性，（如指纹、脸象、虹膜等）和行为特征（如笔迹、声音、步态等）来进行个人身份的鉴定。本项目的目标是，将UKUI移植到openEuler,并移植、适配、完善已有的生物识别框架，使得在openEuler上，用户可以通过指纹仪、指静脉、虹膜等设备进行登录系统、提权等操作。 + +_难度_ 中 + +_导师_ + +- [@dou33](https://gitee.com/dou33) +- [@handsome_feng](https://gitee.com/handsome_feng) + +_联系方式_ + +- douyan@kylinos.cn +- jianfengli@ubuntukylin.com + +_任务链接_ https://gitee.com/openeuler/marketing/issues/I1IRJ3 \ No newline at end of file -- GitLab