Hi, Don't you remember the topic "solid state drive access and context switching" [1]. I want to measure it is really better performance on SSD? To write it on ssd synchronously, I hacked the 'generic_make_request()' [2] and got following results. # echo 3 > /proc/sys/vm/drop_caches # tiotest -f 100 -R -d /dev/sdd1 Tiotest results for 4 concurrent io threads: | Write 400 MBs | 4.7 s | 84.306 MB/s | 8.4 % | 77.5 % | | Read 400 MBs | 4.3 s | 92.945 MB/s | 7.2 % | 53.5 % | Tiotest latency results: | Write | 0.126 ms | 706.379 ms | 0.00000 | 0.00000 | | Read | 0.161 ms | 311.738 ms | 0.00000 | 0.00000 | # echo 3 > /proc/sys/vm/drop_caches # tiotest -f 1000 -R -d /dev/sdd1 Tiotest results for 4 concurrent io threads: | Write 4000 MBs | 47.5 s | 84.124 MB/s | 7.0 % | 83.6 % | | Read 4000 MBs | 41.9 s | 95.530 MB/s | 7.8 % | 55.6 % | Tiotest latency results: | Write | 0.176 ms | 714.677 ms | 0.00000 | 0.00000 | | Read | 0.161 ms | 311.815 ms | 0.00000 | 0.00000 | However it's same performance as before. It means the patch is meaningless. Could you tell me is it the proper place to hack or others? Thank you, Kyungmin Park p.s. Of cource I got the following message WARNING: at block/blk-core.c:1351 generic_make_request+0x126/0x3d8() 1. http://lkml.org/lkml/2007/12/3/247 2. simple hack diff --git a/block/blk-core.c b/block/blk-core.c index e9754dc..7262720 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1345,6 +1345,14 @@ static inline void __generic_make_request(struct bio *bio) if (bio_check_eod(bio, nr_sectors)) goto end_io; + /* FIXME simple hack by kmpark */ + if (MINOR(bio->bi_bdev->bd_dev) == 49 && + MAJOR(bio->bi_bdev->bd_dev) == 8 && bio_data_dir(bio) == WRITE) { + WARN_ON_ONCE(1); + /* Write synchronous */ + bio->bi_rw |= (1 << BIO_RW_SYNC); + } + /* * Resolve the mapping until finished. (drivers are * still free to implement/resolve their own stacking - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
