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]
Message-ID: <9c9fda240802182148m6fd632pa7988530c5387245@mail.gmail.com>
Date:	Tue, 19 Feb 2008 14:48:18 +0900
From:	"Kyungmin Park" <kmpark@...radead.org>
To:	"Linux Filesystem Mailing List" <linux-fsdevel@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Question about synchronous write on SSD

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ