Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SoC2020] PostgreSQL: add io_uring support #9

Open
josephhz opened this issue May 21, 2020 · 4 comments
Open

[SoC2020] PostgreSQL: add io_uring support #9

josephhz opened this issue May 21, 2020 · 4 comments

Comments

@josephhz
Copy link
Contributor

项目名称/Project Title

PostgreSQL: 增加 io_uring 支持
PostgreSQL: add io_uring support

项目描述/Project Description

PostgreSQL 是一款强大的开源对象-关系数据库服务器(ORDBMS),特点是可靠,特性健壮以及高性能,且支持跨平台。PostgreSQL 的 Slogan 是“世界上最先进的开源关系型数据库”,其官网链接:https://www.postgresql.org/

本项目计划在 PostgreSQL 中增加对 io_uring 的支持,以优化异步 io 模型的性能,目前社区也有在做这方面的尝试。参考资料:https://anarazel.de/talks/2020-01-31-fosdem-aio/aio.pdf

PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance. It supports running corss-platform. The slogan of PostgreSQL is "The World's Most Advanced Open Source Relational Database", as seen on the offical website is https://www.postgresql.org/.

This project wants to add io_uring support for PostgreSQL, to achieve better performance by using asynchronous io. Now community already has similar attempt, for more details please refer https://anarazel.de/talks/2020-01-31-fosdem-aio/aio.pdf

预期成果/Expected Outcomes

  • 通过 PostgreSQL 自带回归测试用例
  • 通过 pgTAP 测试套
  • 支持 io_uring 的 PostgreSQL 版本在 Aliyun Linux 2 上能正常运行
  • 预期相比原始版本性能有 10%+ 的提升

  • Pass PostgreSQL related testcases
  • Pass pgTAP testcases
  • Make PostgreSQL with io_uring support run normally on Aliyun Linux 2
  • Expect 10+ performance optimization compared to original version

需要的技能/Required Skills

  • 熟悉 C 语言编程
  • 熟悉 PostgreSQL 的基本原理机制
  • 熟悉异步 IO(aio/io_uring)

  • Familiar with C
  • Familliar with PostgreSQL
  • Familliar with aio/io_uring
@deepanshu1422
Copy link

@casparant @josephhz Sir, I would like to work upon this issue #9

@josephhz
Copy link
Contributor Author

josephhz commented Jun 3, 2020

Thanks for taking interest on this project.
Please apply it via our official website, which I described in the reply email.

@deepanshu1422
Copy link

@josephhz Thanks for your help and resolving the issues,
I have submitted the same through the official form :)

@josephhz
Copy link
Contributor Author

@josephhz Thanks for your help and resolving the issues,
I have submitted the same through the official form :)
You are welcome. Will announce the selected proposal according to timeline.

shiloong pushed a commit that referenced this issue Jan 12, 2022
to #30401861

commit 28dd29c upstream

Make sure to return a proper negative error code from copy_process()
when anon_inode_getfile() fails with CLONE_PIDFD.
Otherwise _do_fork() will not detect an error and get_task_pid() will
operator on a nonsensical pointer:

R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c
R13: 00007ffc15fbb0ff R14: 00007ff07e47e9c0 R15: 0000000000000000
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7990 Comm: syz-executor290 Not tainted 5.2.0-rc6+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
RIP: 0010:get_task_pid+0xe1/0x210 kernel/pid.c:372
Code: 89 ff e8 62 27 5f 00 49 8b 07 44 89 f1 4c 8d bc c8 90 01 00 00 eb 0c
e8 0d fe 25 00 49 81 c7 38 05 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 18 00 74
08 4c 89 ff e8 31 27 5f 00 4d 8b 37 e8 f9 47 12 00
RSP: 0018:ffff88808a4a7d78 EFLAGS: 00010203
RAX: 00000000000000a7 RBX: dffffc0000000000 RCX: ffff888088180600
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88808a4a7d90 R08: ffffffff814fb3a8 R09: ffffed1015d66bf8
R10: ffffed1015d66bf8 R11: 1ffff11015d66bf7 R12: 0000000000041ffc
R13: 1ffff11011494fbc R14: 0000000000000000 R15: 000000000000053d
FS:  00007ff07e47e700(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b5100 CR3: 0000000094df2000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  _do_fork+0x1b9/0x5f0 kernel/fork.c:2360
  __do_sys_clone kernel/fork.c:2454 [inline]
  __se_sys_clone kernel/fork.c:2448 [inline]
  __x64_sys_clone+0xc1/0xd0 kernel/fork.c:2448
  do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Link: https://lore.kernel.org/lkml/[email protected]
Reported-and-tested-by: [email protected]
Fixes: 6fd2fe4 ("copy_process(): don't use ksys_close() on cleanups")
Cc: Jann Horn <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>
Signed-off-by: Yang, Wei <[email protected]>
Reviewed-by: Xunlei Pang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants