Kindly find the proposed Timeline of the project idea "MMC and DMA
Linux performance" below as discussed with my mentor.
GOAL OF THE PROJECT-
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.
Timeline -
BONDING PERIOD GOALS -
Identifying the issues with the current MMC and DMA stack in kernel
tree and developing algorithms to solve them.
FIRST WORK PERIOD GOALS -
MMC Driver -
1. Compare the results of baremetal MMC/IO operations with that of
Linux and compare the performance.
2. Profile the different layers, and identify the timing profile of
different operations in the I/O path (from block layers -> MMC SD
->DMA). Also explore tools like kernelshark to draw a timeline of the
I/O path.
SECOND WORK PERIOD GOALS -
DMA Driver -
1. The pages that make up the Scatter-gather segment list passed to
the block layer can be in an "infavorable-order" (although consisting
consecutive pages) in the sense that the list points to pages that
are decreasing in physical memory order so we neede to use ftrace to
figure out where the allocations are coming from.
If there is evidence that out-of-order pages are causing a problem,
then we can study/investigate on improving the allocations.
2. Studying/developing better locking techniques in EDMA driver:
The locks are acquired and released too often in the EDMA driver
(drivers/dma/edma.c) even when there's only one user of the channel.
So there should be a better way to do the locking, possibly using RCU
or doing away with locks altogether. Locks sure don't have much
overhead, but the DMA overhead is not negligible for small block
sizes.
So if there is evidence that locking is a problem then find and
investigate better locking techniques.
Deliverables - Improvement in perfmonace of Linux kernel MMC and DMA
device drivers.
To be fair,
Also add tests to be performed with other platforms such as rpi etc
and different classes of MMC/sd cards; and documenting these.
That should make your investigations in part 1 complete.
FIRST WORK PERIOD GOALS -
MMC Driver -
1. Compare the results of baremetal MMC/IO operations with that of
Linux and compare the performance.
2. Profile the different layers, and identify the timing profile of
different operations in the I/O path (from block layers -> MMC SD
->DMA). Also explore tools like kernelshark to draw a timeline of the
I/O path.
I have already considered testing as an integral part of my
implementation of this project idea since I understand we need to
compare our results with other platforms such as Rasberry-Pi etc and
different classes of MMC/sd cards.
I have chosen a test -suite called LTP_DDT, an extension of the
original Linux Test Project(LTP), and is used by Texas Instruments to
validate Sitara Linux PSP releases. The official link to the
test-suite is present at the below link-
To be fair,
Also add tests to be performed with other platforms such as rpi etc
and different classes of MMC/sd cards; and documenting these.
That should make your investigations in part 1 complete.
FIRST WORK PERIOD GOALS -
MMC Driver -
1. Compare the results of baremetal MMC/IO operations with that of
Linux and compare the performance.
2. Profile the different layers, and identify the timing profile of
different operations in the I/O path (from block layers -> MMC SD
->DMA). Also explore tools like kernelshark to draw a timeline of the
I/O path.
I have already considered testing as an integral part of my
implementation of this project idea since I understand we need to
compare our results with other platforms such as Rasberry-Pi etc and
different classes of MMC/sd cards.
Please mention the platform you're comparing with. Point 1 is quite
incomplete IMO, its good to be specific about RPi for ex,- this will
help you refer back to it later when you're planning the work. Also,
folks are in the process of voting, no one will able to read your mind
about what you thought of doing if its not there in the proposal. Please
be as detailed as possible, I'd be sad if it got rejected because of
lack of details.
As I suggested, also it will be good for your proposal to mention the
fact that comparison with various card classes.
I have chosen a test -suite called LTP_DDT, an extension of the
original Linux Test Project(LTP), and is used by Texas Instruments to
validate Sitara Linux PSP releases. The official link to the
test-suite is present at the below link-
Sounds good. Do mention LTP DDT and stress testing as well in the proposal.
Good luck!