diff for duplicates of <1474073395.10494.13.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index d059a16..a65158e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,33 +1,33 @@ -On Fri, 2016-09-16@11:16 -0700, Andy Lutomirski wrote: +On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote: > Hi all- > -> Here's v4 of the APST patch set.??The biggest bikesheddable thing (I -> think) is the scaling factor.??I currently have it hardcoded so that +> Here's v4 of the APST patch set. The biggest bikesheddable thing (I +> think) is the scaling factor. I currently have it hardcoded so that > we wait 50x the total latency before entering a power saving state. > On my Samsung 950, this means we enter state 3 (70mW, 0.5ms entry > latency, 5ms exit latency) after 275ms and state 4 (5mW, 2ms entry -> latency, 22ms exit latency) after 1200ms.??I have the default max +> latency, 22ms exit latency) after 1200ms. I have the default max > latency set to 25ms. > > FWIW, in practice, the latency this introduces seems to be well > under 22ms, but my benchmark is a bit silly and I might have -> measured it wrong.??I certainly haven't observed a slowdown just +> measured it wrong. I certainly haven't observed a slowdown just > using my laptop. > > This time around, I changed the names of parameters after Jay -> Frayensee got confused by the first try.??Now they are: +> Frayensee got confused by the first try. Now they are: > -> ?- ps_max_latency_us in sysfs: actually controls it. -> ?- nvme_core.default_ps_max_latency_us: sets the default. +> - ps_max_latency_us in sysfs: actually controls it. +> - nvme_core.default_ps_max_latency_us: sets the default. > > Yeah, they're mouthfuls, but they should be clearer now. ->? +> I took the patches and applied them to one of my NVMe fabric hosts on -my NVMe-over-Fabrics setup. ?Basically, it doesn't test much other than -Andy's explanation that?"ps_max_latency_us" does not appear in any of +my NVMe-over-Fabrics setup. Basically, it doesn't test much other than +Andy's explanation that "ps_max_latency_us" does not appear in any of /sys/block/nvmeXnY sysfs nodes (I have 7) so seems good to me on this front. -Tested-by: Jay Freyensee <james_p_freyensee at linux.intel.com> +Tested-by: Jay Freyensee <james_p_freyensee@linux.intel.com> [jpf: defaults benign to NVMe-over-Fabrics] diff --git a/a/content_digest b/N1/content_digest index 4b9bda2..84e8612 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,41 +1,47 @@ "ref\0cover.1474049701.git.luto@kernel.org\0" - "From\0james_p_freyensee@linux.intel.com (J Freyensee)\0" - "Subject\0[PATCH v4 0/3] nvme power saving\0" + "From\0J Freyensee <james_p_freyensee@linux.intel.com>\0" + "Subject\0Re: [PATCH v4 0/3] nvme power saving\0" "Date\0Fri, 16 Sep 2016 17:49:55 -0700\0" + "To\0Andy Lutomirski <luto@kernel.org>" + Keith Busch <keith.busch@intel.com> + " Jens Axboe <axboe@fb.com>\0" + "Cc\0linux-nvme@lists.infradead.org" + Christoph Hellwig <hch@lst.de> + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" - "On Fri, 2016-09-16@11:16 -0700, Andy Lutomirski wrote:\n" + "On Fri, 2016-09-16 at 11:16 -0700, Andy Lutomirski wrote:\n" "> Hi all-\n" "> \n" - "> Here's v4 of the APST patch set.??The biggest bikesheddable thing (I\n" - "> think) is the scaling factor.??I currently have it hardcoded so that\n" + "> Here's v4 of the APST patch set.\302\240\302\240The biggest bikesheddable thing (I\n" + "> think) is the scaling factor.\302\240\302\240I currently have it hardcoded so that\n" "> we wait 50x the total latency before entering a power saving state.\n" "> On my Samsung 950, this means we enter state 3 (70mW, 0.5ms entry\n" "> latency, 5ms exit latency) after 275ms and state 4 (5mW, 2ms entry\n" - "> latency, 22ms exit latency) after 1200ms.??I have the default max\n" + "> latency, 22ms exit latency) after 1200ms.\302\240\302\240I have the default max\n" "> latency set to 25ms.\n" "> \n" "> FWIW, in practice, the latency this introduces seems to be well\n" "> under 22ms, but my benchmark is a bit silly and I might have\n" - "> measured it wrong.??I certainly haven't observed a slowdown just\n" + "> measured it wrong.\302\240\302\240I certainly haven't observed a slowdown just\n" "> using my laptop.\n" "> \n" "> This time around, I changed the names of parameters after Jay\n" - "> Frayensee got confused by the first try.??Now they are:\n" + "> Frayensee got confused by the first try.\302\240\302\240Now they are:\n" "> \n" - "> ?- ps_max_latency_us in sysfs: actually controls it.\n" - "> ?- nvme_core.default_ps_max_latency_us: sets the default.\n" + "> \302\240- ps_max_latency_us in sysfs: actually controls it.\n" + "> \302\240- nvme_core.default_ps_max_latency_us: sets the default.\n" "> \n" "> Yeah, they're mouthfuls, but they should be clearer now.\n" - ">?\n" + ">\302\240\n" "\n" "I took the patches and applied them to one of my NVMe fabric hosts on\n" - "my NVMe-over-Fabrics setup. ?Basically, it doesn't test much other than\n" - "Andy's explanation that?\"ps_max_latency_us\" does not appear in any of\n" + "my NVMe-over-Fabrics setup. \302\240Basically, it doesn't test much other than\n" + "Andy's explanation that\302\240\"ps_max_latency_us\" does not appear in any of\n" "/sys/block/nvmeXnY sysfs nodes (I have 7) so seems good to me on this\n" "front.\n" "\n" - "Tested-by: Jay Freyensee <james_p_freyensee at linux.intel.com>\n" + "Tested-by: Jay Freyensee <james_p_freyensee@linux.intel.com>\n" [jpf: defaults benign to NVMe-over-Fabrics] -51eb65d85344164059d8b1ebb862259de271c25b69f239930b7dc09f2a9bb6e6 +79935b1fb72c162491ba71edd176e08ee99d650796ef16a20ee093997aa68211
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.