Source-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[src/trunk]: src/doc/roadmaps adjust the nvme entry; the flush cache is now a...



details:   https://anonhg.NetBSD.org/src/rev/374ec0c82cf1
branches:  trunk
changeset: 348605:374ec0c82cf1
user:      jdolecek <jdolecek%NetBSD.org@localhost>
date:      Fri Oct 28 20:30:37 2016 +0000

description:
adjust the nvme entry; the flush cache is now asynchronous, and be more
specific for the get/set cache entry too

diffstat:

 doc/roadmaps/storage |  12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diffs (29 lines):

diff -r 989f80aa392a -r 374ec0c82cf1 doc/roadmaps/storage
--- a/doc/roadmaps/storage      Fri Oct 28 20:17:27 2016 +0000
+++ b/doc/roadmaps/storage      Fri Oct 28 20:30:37 2016 +0000
@@ -1,4 +1,4 @@
-$NetBSD: storage,v 1.18 2016/09/21 20:32:47 jdolecek Exp $
+$NetBSD: storage,v 1.19 2016/10/28 20:30:37 jdolecek Exp $
 
 NetBSD Storage Roadmap
 ======================
@@ -225,14 +225,14 @@
  - The nvme driver is a backend to ld(4) which is MPSAFE, but we still
    need to attend to I/O path bottlenecks. Better instrumentation
    is needed.
- - Flush cache commands via DIOCCACHESYNC is currently implemented using polled
-   commands for simplicity, limiting speed to about 10 milliseconds due to use
-   of delay(9); investigate if it's worth changing this to a cv to avoid
-   the delay, especially for journalled/heavy fsync scenarios
+ - Flush cache commands via DIOCCACHESYNC currently doesn't wait for completion;
+   it must not poll since that corrupts command queue, but it should use
+   a condition variable to wait for the flush to actually finish
  - NVMe controllers supports write cache administration via GET/SET FEATURE, but
    driver doesn't currently implement the cache ioctls, leading to somewhat
    ugly dkctl(1) output; it would be fairly simple to add this, but would
-   require small changes to ld(4) attachment code
+   require ld(4) attachment code changed to support passing arbitrary ioctls
+   to attachments
  - There is no clear timeframe or release target for these points.
  - Contact msaitoh or agc for further information.
 



Home | Main Index | Thread Index | Old Index