Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
Hi Chris, On 06.08.2012 17:31, Chris Ball wrote: Hi, On Mon, Aug 06 2012, Dirk Behme wrote: On embedded devices, often there is a combination of removable mmc devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC). Depending on the hardware configuration, the 'mmcblkN' node might change if the removable device is available or not at boot time. E.g. if the removable device is attached at boot time, it might become mmxblk0. And the hard wired one mmcblk1. But if the removable device isn't there at boot time, the hard wired one will become mmcblk0. This makes it somehow difficult to hard code the root device to the non-removable device and boot fast. This change does simply associate 'N' of 'mmcblkN' with the slot index instead of the dynamic name index. The slot index is always the same, ensuring that the non-removable mmc device is associated always with the same mmcblkN. Independent of the availability of the removable one. I like this change in principle, Thanks :) but doesn't it break boot for everyone currently using e.g. root=/dev/mmcblk0p1 on slot index 2? That doesn't sound like an acceptable regression. I'm not really an expert of the code in block.c. Could you imagine a change which has the same result we'd like to get with the proposed patch but doesn't have the regression you mention? Many thanks and best regards Dirk -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] ROW scheduling Algorithm
Hi I tested with this patch on my board. But i didn't get any performance benefit. Which benchmark did you use? And sometime this scheduler didn't work well read/write operation. (i didn't know exactly what problem.) The below is my environment: Kernel Version: linux-3.4 Card: eMMC4.5 (50MHz DDR mode, 8-bit buswidth) Host controller : dw-mmc (DesignWare MMC controller) Benchmark : IOzone *CFQ Scheduler Read : 35MB Write : 17MB *ROW Scheduler Read : 28MB Write : 17MB How do you think about this result? Best Regards, Jaehoon Chung On 08/05/2012 08:30 PM, Tatyana Brokhman wrote: The ROW scheduling algorithm will be used in mobile devices as default block layer IO scheduling algorithm. ROW stands for READ Over WRITE which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have AS much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you’ll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel lmdd read and write. The tests were performed on: kernel version: 3.4 Underline device driver: mmc Host controller: msm-sdcc Card:standard emmc NAND flash -- Algorithm | Throughput [mb/sec] | Worst case Latency [msec] | | READ| WRITE | READ | WRITE | -- Noop |12.12| 25.18 | 4407 | 4804 | Deadline |12.02| 24.6| 705 | 5130 | CFQ |20.81| 15.23 | 230 | 9370 | ROW |27.75| 15.34 | 85 | 12025 | -| Tatyana Brokhman (2): block: Expose kblock_schedule_delayed_work() block: Adding ROW scheduling algorithm Documentation/block/row-iosched.txt | 117 ++ block/Kconfig.iosched | 22 ++ block/Makefile |1 + block/row-iosched.c | 675 +++ include/linux/blkdev.h |2 + 5 files changed, 817 insertions(+), 0 deletions(-) create mode 100644 Documentation/block/row-iosched.txt create mode 100644 block/row-iosched.c -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 0/2] ROW scheduling Algorithm
Hi Chung Hi I tested with this patch on my board. But i didn't get any performance benefit. Which benchmark did you use? As I already mentioned I used lmdd. The results I published were collected using the bellow command run in parallel: adb shell /data/lmdd if=internal of=/data/writefile bs=128k count=3000 adb shell /data/lmdd if=/data/readfile of=internal bs=128k count=3000 With lmdd we did see great improvement both in throughput and in read latency: CFQ: READ 20.81 MB/sec,WRITE 15.23 MB/sec Worst case READ latency 230 msec Worst case write latency 9370 msec ROW: READ 27.75 MB/sec WRITE 15.34 MB/sec Worst case READ latency 85 msec Worst case write latency 12025 msec ROW can be configured to perform at ~34 MB/sec throughput in the above scenario but in this configuration worst case write latency increases to ~13 sec. And sometime this scheduler didn't work well read/write operation. (i didn't know exactly what problem.) This may be. We're still working on testing the scheduler and improving it. It's not yet totally bug free. I've uploaded the code as RFC. The below is my environment: Kernel Version: linux-3.4 Card: eMMC4.5 (50MHz DDR mode, 8-bit buswidth) Host controller : dw- mmc (DesignWare MMC controller) Benchmark : IOzone My environment is similar except the host controller which is msm-sdcc. Could you please give me the exact iozone command you used? I'll replay it on my setup. Thanks, Tanya Brokhman --- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/2] SD/MMC: add an interface to re-initialize bounce buffer
Add attribute bouncesz under sysfs.
Provide a helper of dynamic adjustment of bounce buffer for SDMA mmc card at
run-time (mounted or unmounted filesystem).
bouncesz should be integer multiple of 512, the value range is from 4K to 4M.
1. use variable instead of MMC_QUEUE_BOUNCESZ;
2. Re-initialize bounce buffer accorinding to new bounce size at run-time;
Cc: Chris Ball c...@laptop.org
Cc: Rob Landley r...@landley.net
Signed-off-by: Qiang Liu qiang@freescale.com
---
Hi all,
I resend the patch because bounce size is a key factor of performance for some
SDMA card, larger bounce size will improve throughput under condition of mass
data transfer. So I add this helper and export the value to user space.
drivers/mmc/card/block.c | 48 +
drivers/mmc/card/queue.c | 102 +-
drivers/mmc/card/queue.h |6 +++
3 files changed, 155 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f1c84de..3ea4ac3 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -58,6 +58,9 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
+#define MMC_MIN_QUEUE_BOUNCESZ 4096
+#define MMC_MAX_QUEUE_BOUNCESZ 4194304
+
static DEFINE_MUTEX(block_mutex);
/*
@@ -107,6 +110,7 @@ struct mmc_blk_data {
unsigned intpart_curr;
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
+ struct device_attribute bouncesz;
int area_type;
};
@@ -263,6 +267,33 @@ out:
return ret;
}
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+static ssize_t mmc_bouncesz_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+return sprintf(buf, %u\n, mmc_queue_bouncesz);
+}
+
+static ssize_t mmc_bouncesz_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned int bouncesz;
+ struct mmc_blk_data *md;
+
+ if ((sscanf(buf, %d, bouncesz) != 1) ||
+ (bouncesz MMC_MIN_QUEUE_BOUNCESZ) ||
+ (bouncesz MMC_MAX_QUEUE_BOUNCESZ) ||
+ (bouncesz % 512 != 0))
+ return -EINVAL;
+
+ md = mmc_blk_get(dev_to_disk(dev));
+ mmc_reinit_bounce_queue(md-queue, md-queue.card, bouncesz);
+ mmc_blk_put(md);
+ return mmc_queue_bouncesz;
+}
+#endif
+
static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
{
struct mmc_blk_data *md = mmc_blk_get(bdev-bd_disk);
@@ -1648,6 +1679,8 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md)
del_gendisk(md-disk);
}
+ device_remove_file(disk_to_dev(md-disk), md-bouncesz);
+
/* Then flush out any already in there */
mmc_cleanup_queue(md-queue);
mmc_blk_put(md);
@@ -1683,6 +1716,17 @@ static int mmc_add_disk(struct mmc_blk_data *md)
if (ret)
goto force_ro_fail;
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+ md-bouncesz.show = mmc_bouncesz_show;
+ md-bouncesz.store = mmc_bouncesz_store;
+ sysfs_attr_init(md-bouncesz.attr);
+ md-bouncesz.attr.name = bouncesz;
+ md-bouncesz.attr.mode = S_IRUGO | S_IWUSR;
+ ret = device_create_file(disk_to_dev(md-disk), md-bouncesz);
+ if (ret)
+ goto bouncesz_fail;
+#endif
+
if ((md-area_type MMC_BLK_DATA_AREA_BOOT)
card-ext_csd.boot_ro_lockable) {
umode_t mode;
@@ -1707,6 +1751,10 @@ static int mmc_add_disk(struct mmc_blk_data *md)
power_ro_lock_fail:
device_remove_file(disk_to_dev(md-disk), md-force_ro);
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+bouncesz_fail:
+ device_remove_file(disk_to_dev(md-disk), md-bouncesz);
+#endif
force_ro_fail:
del_gendisk(md-disk);
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index e360a97..b9777a5 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -22,6 +22,10 @@
#define MMC_QUEUE_BOUNCESZ 65536
+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+unsigned mmc_queue_bouncesz = MMC_QUEUE_BOUNCESZ;
+#endif
+
#define MMC_QUEUE_SUSPENDED(1 0)
/*
@@ -188,7 +192,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card,
if (host-max_segs == 1) {
unsigned int bouncesz;
- bouncesz = MMC_QUEUE_BOUNCESZ;
+ bouncesz = mmc_queue_bouncesz;
if (bouncesz host-max_req_size)
bouncesz = host-max_req_size;
@@ -332,6 +336,102 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
EXPORT_SYMBOL(mmc_cleanup_queue);
/**
+ * mmc_reinit_bounce_queue - re-initialise a bounce buffer.
+ * @mq: mmc queue
+ * @card: mmc card to attach this queue
+ * @bouncesz: the bounce size that need re-initializing
+ *
+ * Initialise a MMC card request queue.
+ */
[PATCH RESEND 2/2] mmc/doc: feature description of runtime bounce buffer size adjustment
Add feature description of attribute bounce buffer size. Cc: Chris Ball c...@laptop.org Cc: Rob Landley r...@landley.net Signed-off-by: Qiang Liu qiang@freescale.com --- Documentation/mmc/mmc-dev-attrs.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index 22ae844..8299433 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -7,6 +7,8 @@ SD or MMC device. The following attributes are read/write. force_roEnforce read-only access even if write protect switch is off. + bounceszSupport dynamic adjustment of bounce buffer size at runtime, + from 4K to 4M, integer multiple of 512 bytes only. SD and MMC Device Attributes -- 1.7.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] ROW scheduling Algorithm
On 08/08/2012 07:37 PM, Tanya Brokhman wrote: Hi Chung Hi I tested with this patch on my board. But i didn't get any performance benefit. Which benchmark did you use? As I already mentioned I used lmdd. The results I published were collected using the bellow command run in parallel: adb shell /data/lmdd if=internal of=/data/writefile bs=128k count=3000 adb shell /data/lmdd if=/data/readfile of=internal bs=128k count=3000 With lmdd we did see great improvement both in throughput and in read latency: CFQ: READ 20.81 MB/sec,WRITE 15.23 MB/sec Worst case READ latency 230 msec Worst case write latency 9370 msec ROW: READ 27.75 MB/sec WRITE 15.34 MB/sec Worst case READ latency 85 msec Worst case write latency 12025 msec ROW can be configured to perform at ~34 MB/sec throughput in the above scenario but in this configuration worst case write latency increases to ~13 sec. I will try to test with lmdd. And sometime this scheduler didn't work well read/write operation. (i didn't know exactly what problem.) This may be. We're still working on testing the scheduler and improving it. It's not yet totally bug free. I've uploaded the code as RFC. The below is my environment: Kernel Version: linux-3.4 Card: eMMC4.5 (50MHz DDR mode, 8-bit buswidth) Host controller : dw- mmc (DesignWare MMC controller) Benchmark : IOzone My environment is similar except the host controller which is msm-sdcc. Could you please give me the exact iozone command you used? I'll replay it on my setup. iozone -A -s 200m -U /data/ -f /data/test -e and iozone -A -s 200m -f /data/test -e -I Best Regards, Jaehoon Chung Thanks, Tanya Brokhman --- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
