[OpenAFS-devel] GSoC 2025 Application: OpenAFS Linux Kernel Module - Multi-page Folio
Support Implementation
Sushil Pandey
contact.sushilpandey@gmail.com
Fri, 14 Mar 2025 11:13:25 +0530
--0000000000007ea511063046ebbd
Content-Type: text/plain; charset="UTF-8"
Dear OpenAFS team,
I'm Sushil Pandey, a Computer Science engineering student with experience
in Linux kernel development, particularly in memory management subsystems.
I'm writing to express my interest in the "OpenAFS Linux kernel module:
Multi-page folio support" GSoC project.
During my previous internship, I worked on optimizing page cache
utilization for a custom storage driver, which gave me hands-on experience
with the Linux kernel's memory subsystem and folio API transitions. I've
also contributed patches to fix memory leaks in the NFS client code, which
required understanding similar VFS interfaces that OpenAFS interacts with.
I've been analyzing the OpenAFS codebase, specifically the memory
management in afs/LINUX/osi_vm.c and afs/LINUX/osi_file.c, and see several
opportunities where multi-page folios could improve performance,
particularly in the readpage/writepage implementations and during bulk data
transfers. I believe the afs_linux_storeproc() and afs_linux_fillpages()
functions are key candidates for optimizing with multi-page folios.
I have some specific questions regarding implementation details:
1. Has OpenAFS considered an incremental approach where multi-page folios
are first implemented for read operations before tackling the more complex
write paths with their consistency requirements?
2. Are there specific benchmarks or workloads you're targeting for
performance improvements with multi-page folios, such as large sequential
reads or specific application patterns?
3. How should the implementation handle kernel version compatibility,
particularly for kernels before 5.16 where folio support was still
evolving? Should we maintain parallel code paths or use feature detection?
I've already started drafting a 12-week timeline for this project, dividing
the work into analysis, implementation, and testing phases with specific
milestones for each component of the file system. I would greatly
appreciate your feedback on this timeline and any guidance on critical
areas that should receive priority attention.
Thank you for considering my interest in this project. I'm excited about
the opportunity to contribute to OpenAFS's performance on modern Linux
kernels.
--
*Warm regards,Sushil Pandey*
--0000000000007ea511063046ebbd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Dear OpenAFS team,<br>I'm Sushil Pandey, a Comput=
er Science engineering student with experience in Linux kernel development,=
particularly in memory management subsystems. I'm writing to express m=
y interest in the "OpenAFS Linux kernel module: Multi-page folio suppo=
rt" GSoC project.<br><br>During my previous internship, I worked on op=
timizing page cache utilization for a custom storage driver, which gave me =
hands-on experience with the Linux kernel's memory subsystem and folio =
API transitions. I've also contributed patches to fix memory leaks in t=
he NFS client code, which required understanding similar VFS interfaces tha=
t OpenAFS interacts with.<br><br>I've been analyzing the OpenAFS codeba=
se, specifically the memory management in afs/LINUX/osi_vm.c and afs/LINUX/=
osi_file.c, and see several opportunities where multi-page folios could imp=
rove performance, particularly in the readpage/writepage implementations an=
d during bulk data transfers. I believe the afs_linux_storeproc() and afs_l=
inux_fillpages() functions are key candidates for optimizing with multi-pag=
e folios.<br><br>I have some specific questions regarding implementation de=
tails:<br><br>1. Has OpenAFS considered an incremental approach where multi=
-page folios are first implemented for read operations before tackling the =
more complex write paths with their consistency requirements?<br>2. Are the=
re specific benchmarks or workloads you're targeting for performance im=
provements with multi-page folios, such as large sequential reads or specif=
ic application patterns?<br>3. How should the implementation handle kernel =
version compatibility, particularly for kernels before 5.16 where folio sup=
port was still evolving? Should we maintain parallel code paths or use feat=
ure detection?<br><br>I've already started drafting a 12-week timeline =
for this project, dividing the work into analysis, implementation, and test=
ing phases with specific milestones for each component of the file system. =
I would greatly appreciate your feedback on this timeline and any guidance =
on critical areas that should receive priority attention.<br><br>Thank you =
for considering my interest in this project. I'm excited about the oppo=
rtunity to contribute to OpenAFS's performance on modern Linux kernels.=
<br><br></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr"><div style=3D"color:rgb(34,34,34)"><b>Warm regards,<br>Sushil P=
andey</b></div><div style=3D"color:rgb(34,34,34)"></div></div></div></div>
--0000000000007ea511063046ebbd--