Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752546Ab3FIXU0 (ORCPT ); Sun, 9 Jun 2013 19:20:26 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:50186 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751371Ab3FIXUZ (ORCPT ); Sun, 9 Jun 2013 19:20:25 -0400 MIME-Version: 1.0 Date: Sun, 9 Jun 2013 18:20:24 -0500 Message-ID: Subject: Block layer / MMC: Order of segments in SG-list From: Joel A Fernandes To: Linux Kernel Mailing List , Linux OMAP List Cc: "Fernandes, Joel A" , axboe@kernel.dk Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1237 Lines: 31 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/