Question about synchronous write on SSD

[Kyungmin Park]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/