diff for duplicates of <D65D71B1.C5CBF%paf@cray.com> diff --git a/a/1.txt b/N1/1.txt index e038605..59c2004 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,9 +1,9 @@ Same thing as the other one, ll_statahead_thread should not contribute to load. -IMO, mgc_process_log should not contribute to load in the case where it?s -waiting for an import to recover, that?s likely to be a pretty long wait -and doesn?t really represent load. It?s waiting for network recovery, +IMO, mgc_process_log should not contribute to load in the case where it¹s +waiting for an import to recover, that¹s likely to be a pretty long wait +and doesn¹t really represent load. It¹s waiting for network recovery, basically. The OSC functions get the same question as the other ones - they happen @@ -11,12 +11,12 @@ from user threads and from daemons. Curious again what Andreas and/or Oleg think. I think ptlrpc_reconnect_import should probably *not* contribute to load, -it?s waiting for network recovery. +it¹s waiting for network recovery. Same with ptlrpc_recover_import. On 12/18/17, 1:17 AM, "lustre-devel on behalf of NeilBrown" -<lustre-devel-bounces at lists.lustre.org on behalf of neilb@suse.com> wrote: +<lustre-devel-bounces@lists.lustre.org on behalf of neilb@suse.com> wrote: >When the lwi arg has a timeout, but no timeout >callback function, l_wait_event() acts much the same as @@ -607,5 +607,5 @@ On 12/18/17, 1:17 AM, "lustre-devel on behalf of NeilBrown" > >_______________________________________________ >lustre-devel mailing list ->lustre-devel at lists.lustre.org +>lustre-devel@lists.lustre.org >http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org diff --git a/a/content_digest b/N1/content_digest index d2bea27..626fe7f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,7 +1,7 @@ "ref\0151358127190.5099.12792810096274074963.stgit@noble\0" "ref\0151358147993.5099.9887255633793256926.stgit@noble\0" "From\0Patrick Farrell <paf@cray.com>\0" - "Subject\0[lustre-devel] [PATCH 04/16] staging: lustre: use wait_event_timeout() where appropriate.\0" + "Subject\0Re: [lustre-devel] [PATCH 04/16] staging: lustre: use wait_event_timeout() where appropriate.\0" "Date\0Mon, 18 Dec 2017 20:23:40 +0000\0" "To\0NeilBrown <neilb@suse.com>" Oleg Drokin <oleg.drokin@intel.com> @@ -15,9 +15,9 @@ "Same thing as the other one, ll_statahead_thread should not contribute to\n" "load.\n" "\n" - "IMO, mgc_process_log should not contribute to load in the case where it?s\n" - "waiting for an import to recover, that?s likely to be a pretty long wait\n" - "and doesn?t really represent load. It?s waiting for network recovery,\n" + "IMO, mgc_process_log should not contribute to load in the case where it\302\271s\n" + "waiting for an import to recover, that\302\271s likely to be a pretty long wait\n" + "and doesn\302\271t really represent load. It\302\271s waiting for network recovery,\n" "basically.\n" "\n" "The OSC functions get the same question as the other ones - they happen\n" @@ -25,12 +25,12 @@ "Oleg think.\n" "\n" "I think ptlrpc_reconnect_import should probably *not* contribute to load,\n" - "it?s waiting for network recovery.\n" + "it\302\271s waiting for network recovery.\n" "\n" "Same with ptlrpc_recover_import.\n" "\n" "On 12/18/17, 1:17 AM, \"lustre-devel on behalf of NeilBrown\"\n" - "<lustre-devel-bounces at lists.lustre.org on behalf of neilb@suse.com> wrote:\n" + "<lustre-devel-bounces@lists.lustre.org on behalf of neilb@suse.com> wrote:\n" "\n" ">When the lwi arg has a timeout, but no timeout\n" ">callback function, l_wait_event() acts much the same as\n" @@ -621,7 +621,7 @@ ">\n" ">_______________________________________________\n" ">lustre-devel mailing list\n" - ">lustre-devel at lists.lustre.org\n" + ">lustre-devel@lists.lustre.org\n" >http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org -2ef5c5c73feae2f5cc0e0961c2a57be41a5d959ff8742f68aa70b0ce8e99ee03 +29ff4fcce3175d11bb8dfd7dee50c8a39ca0d82c7183ba36ed2aa7bf62f0fff3
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.