diff for duplicates of <1491839741.4199.7.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 12f01d8..27a5f64 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,6 @@ -On Sun, 2017-04-09 at 11:15 +0200, Javier Gonz=E1lez wrote: -> On 8 Apr 2017, at 22.56, Bart Van Assche <bart.vanassche@sandisk.com> wro= -te: -> > On 04/07/17 11:50, Javier Gonz=E1lez wrote: +On Sun, 2017-04-09 at 11:15 +0200, Javier González wrote: +> On 8 Apr 2017, at 22.56, Bart Van Assche <bart.vanassche@sandisk.com> wrote: +> > On 04/07/17 11:50, Javier González wrote: > struct ppa_addr, which is the physical address format is not affected, > but pblk's internal L2P address representation (pblk_addr) is. You can > see that the type either represents struct ppa_addr or ppa_addr_32. How @@ -11,8 +10,7 @@ te: Selecting the appropriate representation at run-time would require to pass pblk_addr by reference instead of by value to any function that expects a -pblk_addr. It would also require to have two versions of every data structu= -re +pblk_addr. It would also require to have two versions of every data structure that depends on pblk_addr and to use casts to convert to the appropritate version. However, this approach is probably only worth to be implemented if it doesn't introduce too much additional complexity. @@ -21,11 +19,11 @@ it doesn't introduce too much additional complexity. > > > + atomic_add(nr_entries, &pblk->inflight_writes); > > > + atomic_add(nr_entries, &pblk->req_writes); > > > +#endif -> >=20 +> > > > Has it been considered to use the "static key" feature such that > > consistency checks can be enabled at run-time instead of having to > > rebuild the kernel to enable CONFIG_NVM_DEBUG? ->=20 +> > I haven't considered it. I'll look into it. I would like to have this > counters and the corresponding sysfs entry only available on debug mode > since it allows us to have a good picture of the FTL state. @@ -34,15 +32,12 @@ If there are sysfs entries that depend on CONFIG_NVM_DEBUG then the static key mechanism is probably not a good alternative for CONFIG_NVM_DEBUG. > > Has it been considered to add support for keeping a subset of the L2P -> > translation table in memory instead of keeping it in memory in its enti= -rety? ->=20 +> > translation table in memory instead of keeping it in memory in its entirety? +> > Yes. L2P caching is on our roadmap and will be included in the future. -That's great. This will also help with reducing the time between discovery = -of -a lightnvm device and the time at which I/O can start since the L2P table m= -ust +That's great. This will also help with reducing the time between discovery of +a lightnvm device and the time at which I/O can start since the L2P table must be available before I/O can start. -Bart.= +Bart. diff --git a/a/content_digest b/N1/content_digest index 836644b..b5cb449 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -11,10 +11,9 @@ " linux-block@vger.kernel.org <linux-block@vger.kernel.org>\0" "\00:1\0" "b\0" - "On Sun, 2017-04-09 at 11:15 +0200, Javier Gonz=E1lez wrote:\n" - "> On 8 Apr 2017, at 22.56, Bart Van Assche <bart.vanassche@sandisk.com> wro=\n" - "te:\n" - "> > On 04/07/17 11:50, Javier Gonz=E1lez wrote:\n" + "On Sun, 2017-04-09 at 11:15 +0200, Javier Gonz\303\241lez wrote:\n" + "> On 8 Apr 2017, at 22.56, Bart Van Assche <bart.vanassche@sandisk.com> wrote:\n" + "> > On 04/07/17 11:50, Javier Gonz\303\241lez wrote:\n" "> struct ppa_addr, which is the physical address format is not affected,\n" "> but pblk's internal L2P address representation (pblk_addr) is. You can\n" "> see that the type either represents struct ppa_addr or ppa_addr_32. How\n" @@ -24,8 +23,7 @@ "\n" "Selecting the appropriate representation at run-time would require to pass\n" "pblk_addr by reference instead of by value to any function that expects a\n" - "pblk_addr. It would also require to have two versions of every data structu=\n" - "re\n" + "pblk_addr. It would also require to have two versions of every data structure\n" "that depends on pblk_addr and to use casts to convert to the appropritate\n" "version. However, this approach is probably only worth to be implemented if\n" "it doesn't introduce too much additional complexity.\n" @@ -34,11 +32,11 @@ "> > > +\tatomic_add(nr_entries, &pblk->inflight_writes);\n" "> > > +\tatomic_add(nr_entries, &pblk->req_writes);\n" "> > > +#endif\n" - "> >=20\n" + "> > \n" "> > Has it been considered to use the \"static key\" feature such that\n" "> > consistency checks can be enabled at run-time instead of having to\n" "> > rebuild the kernel to enable CONFIG_NVM_DEBUG?\n" - ">=20\n" + "> \n" "> I haven't considered it. I'll look into it. I would like to have this\n" "> counters and the corresponding sysfs entry only available on debug mode\n" "> since it allows us to have a good picture of the FTL state.\n" @@ -47,17 +45,14 @@ "key mechanism is probably not a good alternative for CONFIG_NVM_DEBUG.\n" "\n" "> > Has it been considered to add support for keeping a subset of the L2P\n" - "> > translation table in memory instead of keeping it in memory in its enti=\n" - "rety?\n" - ">=20\n" + "> > translation table in memory instead of keeping it in memory in its entirety?\n" + "> \n" "> Yes. L2P caching is on our roadmap and will be included in the future.\n" "\n" - "That's great. This will also help with reducing the time between discovery =\n" - "of\n" - "a lightnvm device and the time at which I/O can start since the L2P table m=\n" - "ust\n" + "That's great. This will also help with reducing the time between discovery of\n" + "a lightnvm device and the time at which I/O can start since the L2P table must\n" "be available before I/O can start.\n" "\n" - Bart.= + Bart. -363d3f493f86b66f15cd20360011074f06e08e682039bbb10f9e3e7f7a98edeb +03c3217c2603347a5f49496e1cff7a63359417e825ae2cf2c55fd2b32ae5c09b
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.