linux-kernel - Block layer / MMC: Order of segments in SG-list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 9 Jun 2013 18:20:24 -0500
From:	Joel A Fernandes <agnel.joel@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux OMAP List <linux-omap@...r.kernel.org>
Cc:	"Fernandes, Joel A" <joelagnel@...com>, axboe@...nel.dk
Subject: Block layer / MMC: Order of segments in SG-list

Hi,
So I tried dumping addresses of an SG list in omap_hsmmc driver before
it is passed to DMA.

I found some interesting traces occasionally such as the below SG list
of length 4.

[    6.758716] (0) length=4096, sg virt addr=c1318000, sg phy addr=81318000
[    6.765863] (1) length=4096, sg virt addr=c1317000, sg phy addr=81317000
[    6.773011] (2) length=4096, sg virt addr=c1316000, sg phy addr=81316000
[    6.780087] (3) length=4096, sg virt addr=c1315000, sg phy addr=81315000

What is interesting is these chunks are really physically contiguous
but in reverse order in the list. I think a smarter ordering can
actually improve through put considerably and save precious DMA
resources by not having to allocate slots for parts of contiguous
chunk of physical memory.

Is there any particular reason why this might be the case? I traced to
find that the SG list is actually prepared by mmc_queue_map_sg ->
blk_rq_map_sg

Thanks in advance on any insight on the above.

Regards,
Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/