Re: Call for GSoC internship project ideas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07.02.25 14:41, Stefan Hajnoczi wrote:
On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@xxxxxxxxxx> wrote:
On 28.01.25 17:16, Stefan Hajnoczi wrote:
Dear QEMU and KVM communities,
QEMU will apply for the Google Summer of Code internship
program again this year. Regular contributors can submit project
ideas that they'd like to mentor by replying to this email by
February 7th.

About Google Summer of Code
-----------------------------------------
GSoC (https://summerofcode.withgoogle.com/) offers paid open
source remote work internships to eligible people wishing to participate
in open source development. QEMU has been doing internship for
many years. Our mentors have enjoyed helping talented interns make
their first open source contributions and some former interns continue
to participate today.

Who can mentor
----------------------
Regular contributors to QEMU and KVM can participate as mentors.
Mentorship involves about 5 hours of time commitment per week to
communicate with the intern, review their patches, etc. Time is also
required during the intern selection phase to communicate with
applicants. Being a mentor is an opportunity to help someone get
started in open source development, will give you experience with
managing a project in a low-stakes environment, and a chance to
explore interesting technical ideas that you may not have time to
develop yourself.

How to propose your idea
------------------------------
Reply to this email with the following project idea template filled in:

=== TITLE ===

'''Summary:''' Short description of the project

Detailed description of the project that explains the general idea,
including a list of high-level tasks that will be completed by the
project, and provides enough background for someone unfamiliar with
the code base to research the idea. Typically 2 or 3 paragraphs.

'''Links:'''
* Links to mailing lists threads, git repos, or web sites

'''Details:'''
* Skill level: beginner or intermediate or advanced
* Language: C/Python/Rust/etc
=== Asynchronous request handling for virtiofsd ===

'''Summary:''' Make virtiofsd’s request handling asynchronous, allowing
single-threaded parallel request processing.

virtiofsd is a virtio-fs device implementation, i.e. grants VM guests
access to host directories. In its current state, it processes guest
requests one by one, which means operations of long duration will block
processing of others that could be processed more quickly.

With asynchronous request processing, longer-lasting operations could
continue in the background while other requests with lower latency are
fetched and processed in parallel. This should improve performance
especially for mixed workloads, i.e. one guest process executing
longer-lasting filesystem operations, while another runs random small
read requests on a single file.

Your task is to:
* Get familiar with a Linux AIO interface, preferably io_uring
* Have virtiofsd make use of that interface for its operations
* Make the virtiofsd request loop process requests asynchronously, so
requests can be fetched and processed while others are continuing in the
background
* Evaluate the resulting performance with different workloads

'''Links:'''
* virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
* virtiofsd’s filesystem operations:
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
* virtiofsd’s request processing loop:
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244

'''Details:'''
* Skill level: intermediate
* Language: Rust
* Mentors: Hanna Czenczek (hreitz@xxxxxxxxxx), German Maglione
(gmaglione@xxxxxxxxxx)
Thanks, I have added your project idea to the list:
https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd

Thanks!

Do you want to give any guidance on which crate to use for
asynchronous I/O? Do you want async Rust (e.g. tokio) or not?

That would depend entirely on the student.  I’m open for async Rust (tokio or even homegrown), but they could also decide they’d rather do it in some different manner (e.g. with callbacks that would return descriptors to the guest).  I’ll add that info, if that’s OK.

Hanna





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux