Interested Candidates: Idea to improve "MMC and DMA Linux performance on Beaglebone"

With 2 days left for student application freeze, I am a bit concerned no one
has picked up the idea I posted on the wiki and wanted to start a discussion
for any interested candidates, about any concerns students may have.

The idea can be read at:
(http://elinux.org/BeagleBoard/GSoC/Ideas#MMC_and_DMA_Linux_performance)
and is pasted at the end of this email.

This is a good project for folks “familiar” with kernel programming and are
knowledgeable in the embedded Linux ways to as a starting point to contributing
code to upstream kernel and working on some interesting system level issues.

If students did read it on the wiki earlier, and the reaction was more of “Its
too tough”, instead of a reaction “I don’t think I’m that interested”, then
that certainly can be helped, and it’d be great to get your thoughts and
concerns out in this thread.

The deadline is fast approaching, so do respond soon!

Cheers,

-Joel

MMC and DMA Linux performance on Beaglebone

Improving performance of MMC driver by understanding issues, improving MMC, DMA
drivers and eliminating bottlenecks.

Goal: Both MMC and DMA are critical to high performance of I/O intensive
workloads on a Beagleboard/ARM platform, even fast system boot up depends on
it.

A good amount of performance improvement is possible just by identifying what’s
going on in hot paths and how things can be done more simply, without breaking
anything else. Also improvements are possible using innovative techniques such
as intelligent buffer allocation and reducing overhead where possible in
dependent components such as DMA. Cutting the fat in hot paths is definitely a
start.

Existing Project: Upstream Kernel Hardware Skills: Yes Software Skills: C,
Possible use of JTAG, ftrace, perf etc. Possible mentors: Joel Fernandes

Hi Joel!
I have been working on the Arduino Compatible Library using Starterware project till now. I was also fascinated by this project, but decided against it as I thought it would be too tough.
I have a few questions, maybe the answers could allow me to think about it clearly.

First, will we be creating a new interface for MMCs from the scratch? I understand how important this is to allow a speedy boot, so our focus will be to create a new API for same? Or we will be working on the existing one and try to improve it?

Also, is the present structure based on uboot? How do you suggest where to look for optimization to improve the performance?

Regards,
Naman

Hi Joel,

Please find my response inline.

This is a good project for folks "familiar" with kernel programming and are
knowledgeable in the embedded Linux ways to as a starting point to
contributing
code to upstream kernel and working on some interesting system level issues.

I have experience with kernel programming and have worked on device
drivers which includes Block drivers, USB Mass storage and File
System Drivers. On embedded side, I have worked with Device trees,
U-boot, Busybox, Qemu and done most of my projects on ARM platform
itself but still I am more interested in working on Linux kernel side
in this GSOC rather in Linux user-space . Are my skills and interests,
a match for this project?

If students did read it on the wiki earlier, and the reaction was more of
"Its
too tough", instead of a reaction "I don't think I'm that interested", then
that certainly can be helped, and it'd be great to get your thoughts and
concerns out in this thread.

I would like to at-least like to mention why I did not respond to it.
I was because I haven't worked with either DMA or MMC driver.

Regards,
Saket Sinha

Hi Joel!
I have been working on the Arduino Compatible Library using Starterware
project till now. I was also fascinated by this project, but decided against
it as I thought it would be too tough.
I have a few questions, maybe the answers could allow me to think about it
clearly.

First, will we be creating a new interface for MMCs from the scratch? I
understand how important this is to allow a speedy boot, so our focus will
be to create a new API for same? Or we will be working on the existing one
and try to improve it?

Certainly the goal is just to improve the existing code, this should
be clear in the description.

Also, is the present structure based on uboot? How do you suggest where to
look for optimization to improve the performance?

Strictly speaking, improvements just to the Linux kernel in an area
related to the I/O path. U-boot can be improvement but I doubt that is
of much benefit since the goal is not just boot time but also run time
improvement.

Yes, I suppose it may be a bit too much for someone who hasn't
tinkered with the kernel much, that said you're welcome to ofcourse
keep an eye on the projects and work with folks who may be working on
it and possibly help with some testing to begin with.

Regards,
-Joel

Hi Joel,

Please find my response inline.

This is a good project for folks "familiar" with kernel programming and are
knowledgeable in the embedded Linux ways to as a starting point to
contributing
code to upstream kernel and working on some interesting system level issues.

I have experience with kernel programming and have worked on device
drivers which includes Block drivers, USB Mass storage and File
System Drivers. On embedded side, I have worked with Device trees,
U-boot, Busybox, Qemu and done most of my projects on ARM platform
itself but still I am more interested in working on Linux kernel side
in this GSOC rather in Linux user-space . Are my skills and interests,
a match for this project?

May be in a you could describe a bit more of what exactly have you
done in these areas in specifics? Its hard to comment without knowing
specifics. Though it is good to know your familiarity.

If students did read it on the wiki earlier, and the reaction was more of
"Its
too tough", instead of a reaction "I don't think I'm that interested", then
that certainly can be helped, and it'd be great to get your thoughts and
concerns out in this thread.

I would like to at-least like to mention why I did not respond to it.
I was because I haven't worked with either DMA or MMC driver.

There might be a learning curve, but its certainly not impossible to
pick up knowledge of these stacks. After all, it depends on your
interest.

The fact that you're familiar with kernel programming and hopefully
debugging/tracing tools is a plus.

I welcome to submit a proposal after we can discuss a bit more, and we
can take it from there.

Regards,
-Joel

I have experience with kernel programming and have worked on device
drivers which includes Block drivers, USB Mass storage and File
System Drivers. On embedded side, I have worked with Device trees,
U-boot, Busybox, Qemu and done most of my projects on ARM platform
itself but still I am more interested in working on Linux kernel side
in this GSOC rather in Linux user-space . Are my skills and interests,
a match for this project?

May be in a you could describe a bit more of what exactly have you
done in these areas in specifics? Its hard to comment without knowing
specifics. Though it is good to know your familiarity.

I am a GSoC 2013 participant . I had completed my project Hepunion
filesystem with
CERN last summer. You can find more details about me and my project
here

https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/disdi/5785905063264256

Hepunion filesystem is a stackable filesystem I am developing for
CERN( the European Organization for Nuclear Research). CERN needs a
Union filesystem for LHCb(Large Hadron Collider Beauty) to provide
fast diskless booting for LHCb's nodes. For such an implementation,
they need a file system with two branches a Read-Write and a Read Only
so they decided to write a completely new union file system called
Hepunion.

On embedded side(I mean on ARM platform), I have worked on OMAP
L138(ARM9 +DSP) to bringup a Linux based Locomotive Logger. I was
involved in configuring development enviroment, U-boot setup, builting
root filesystem with BusyBox, used device trees and then some
application level programming with threads and processes.

The fact that you're familiar with kernel programming and hopefully
debugging/tracing tools is a plus.

I have used KGDB, KDB, system tap, crash utility etc for kernel level
debugging and GDB, JTAG for userspace debugging.

Regards,
Saket Sinha

Ok great, based on what you said I think you can definitely take up
the idea. I suggest entering it into the system by today or tomorrow
so that it "into" the system, and then you can work on refining it
based on mentor review.

Let me know if you need any help.

Thanks!

-Joel

Hello everyone,

My name is Saket Sinha and my proposal for GSOC2014 the following
link for "MMC and DMA Linux
performance"-

http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/disdi/5808496591241216

Regards,
Saket Sinha