diff for duplicates of <1520276852.10396.351.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index be4fdd9..9836c28 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,11 +13,11 @@ On Mon, 2018-03-05 at 20:01 +0200, Jarkko Sakkinen wrote: > > > > > - tpm_msleep(TPM_TIMEOUT); > > > > > + tpm_msleep(TPM_TIMEOUT_POLL); > > > > What about just calling schedule()? -> > > I'm not sure what you mean by "schedule()". Are you suggesting instead of -> > > using usleep_range(), using something with an even finer grain construct? +> > > I'm not sure what you mean by "schedule()".? Are you suggesting instead of +> > > using usleep_range(),? using something with an even finer grain construct? > > > > > > Thanks & Regards, -> > > - Nayna +> > > ???? - Nayna > > > > kernel/sched/core.c > @@ -26,18 +26,23 @@ On Mon, 2018-03-05 at 20:01 +0200, Jarkko Sakkinen wrote: > iteration? I still don't understand why scheduling some work would be an -improvement. We still need to loop, testing for the TPM command to +improvement. ?We still need to loop, testing for the TPM command to complete. According to the schedule_hrtimeout_range() function comment, schedule_hrtimeout_range() is both power and performance friendly. - What we didn't realize is that the hrtimer *uses* the maximum range +?What we didn't realize is that the hrtimer *uses* the maximum range to calculate the sleep time, but *may* return earlier based on the minimum time. -This patch minimizes the tpm_msleep(). The subsequent patch in this -patch set shows that 1 msec isn't fine enough granularity. I still +This patch minimizes the tpm_msleep(). ?The subsequent patch in this +patch set shows that 1 msec isn't fine enough granularity. ?I still think calling usleep_range() is the right solution, but it needs to be at a finer granularity than tpm_msleep() provides. Mimi + +-- +To unsubscribe from this list: send the line "unsubscribe linux-security-module" in +the body of a message to majordomo at vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index b28eb4f..ed55634 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,18 +4,10 @@ "ref\06ef601be-5627-6746-bd4a-4f391aba8b04@linux.vnet.ibm.com\0" "ref\020180305105633.GE25377@linux.intel.com\0" "ref\020180305180144.GE5791@linux.intel.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH 2/3] tpm: reduce poll sleep time between send() and recv() in tpm_transmit()\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH 2/3] tpm: reduce poll sleep time between send() and recv() in tpm_transmit()\0" "Date\0Mon, 05 Mar 2018 14:07:32 -0500\0" - "To\0Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>" - " Nayna Jain <nayna@linux.vnet.ibm.com>\0" - "Cc\0linux-integrity@vger.kernel.org" - linux-security-module@vger.kernel.org - linux-kernel@vger.kernel.org - peterhuewe@gmx.de - tpmdd@selhorst.net - jgunthorpe@obsidianresearch.com - " patrickc@us.ibm.com\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Mon, 2018-03-05 at 20:01 +0200, Jarkko Sakkinen wrote:\n" @@ -33,11 +25,11 @@ "> > > > > -\t\ttpm_msleep(TPM_TIMEOUT);\n" "> > > > > +\t\ttpm_msleep(TPM_TIMEOUT_POLL);\n" "> > > > What about just calling schedule()?\n" - "> > > I'm not sure what you mean by \"schedule()\". Are you suggesting instead of\n" - "> > > using usleep_range(), using something with an even finer grain construct?\n" + "> > > I'm not sure what you mean by \"schedule()\".? Are you suggesting instead of\n" + "> > > using usleep_range(),? using something with an even finer grain construct?\n" "> > > \n" "> > > Thanks & Regards,\n" - "> > > - Nayna\n" + "> > > ???? - Nayna\n" "> > \n" "> > kernel/sched/core.c\n" "> \n" @@ -46,20 +38,25 @@ "> iteration?\n" "\n" "I still don't understand why scheduling some work would be an\n" - "improvement. We still need to loop, testing for the TPM command to\n" + "improvement. ?We still need to loop, testing for the TPM command to\n" "complete.\n" "\n" "According to the schedule_hrtimeout_range() function comment,\n" "schedule_hrtimeout_range() is both power and performance friendly.\n" - " What we didn't realize is that the hrtimer *uses* the maximum range\n" + "?What we didn't realize is that the hrtimer *uses* the maximum range\n" "to calculate the sleep time, but *may* return earlier based on the\n" "minimum time.\n" "\n" - "This patch minimizes the tpm_msleep(). The subsequent patch in this\n" - "patch set shows that 1 msec isn't fine enough granularity. I still\n" + "This patch minimizes the tpm_msleep(). ?The subsequent patch in this\n" + "patch set shows that 1 msec isn't fine enough granularity. ?I still\n" "think calling usleep_range() is the right solution, but it needs to be\n" "at a finer granularity than tpm_msleep() provides.\n" "\n" - Mimi + "Mimi\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -8c040c3f50aea995c8ffe29f6b4d64cdcaed99196642d544d15ac2e5880a3da6 +715b1c24e1a7ce3749a95b09a35bbcaf4f01a4e1e0b4639c7d33cd9aa7e62c98
diff --git a/a/1.txt b/N2/1.txt index be4fdd9..8531cdb 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -13,11 +13,11 @@ On Mon, 2018-03-05 at 20:01 +0200, Jarkko Sakkinen wrote: > > > > > - tpm_msleep(TPM_TIMEOUT); > > > > > + tpm_msleep(TPM_TIMEOUT_POLL); > > > > What about just calling schedule()? -> > > I'm not sure what you mean by "schedule()". Are you suggesting instead of -> > > using usleep_range(), using something with an even finer grain construct? +> > > I'm not sure what you mean by "schedule()". Are you suggesting instead of +> > > using usleep_range(), using something with an even finer grain construct? > > > > > > Thanks & Regards, -> > > - Nayna +> > > - Nayna > > > > kernel/sched/core.c > @@ -26,17 +26,17 @@ On Mon, 2018-03-05 at 20:01 +0200, Jarkko Sakkinen wrote: > iteration? I still don't understand why scheduling some work would be an -improvement. We still need to loop, testing for the TPM command to +improvement. We still need to loop, testing for the TPM command to complete. According to the schedule_hrtimeout_range() function comment, schedule_hrtimeout_range() is both power and performance friendly. - What we didn't realize is that the hrtimer *uses* the maximum range + What we didn't realize is that the hrtimer *uses* the maximum range to calculate the sleep time, but *may* return earlier based on the minimum time. -This patch minimizes the tpm_msleep(). The subsequent patch in this -patch set shows that 1 msec isn't fine enough granularity. I still +This patch minimizes the tpm_msleep(). The subsequent patch in this +patch set shows that 1 msec isn't fine enough granularity. I still think calling usleep_range() is the right solution, but it needs to be at a finer granularity than tpm_msleep() provides. diff --git a/a/content_digest b/N2/content_digest index b28eb4f..728b980 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -33,11 +33,11 @@ "> > > > > -\t\ttpm_msleep(TPM_TIMEOUT);\n" "> > > > > +\t\ttpm_msleep(TPM_TIMEOUT_POLL);\n" "> > > > What about just calling schedule()?\n" - "> > > I'm not sure what you mean by \"schedule()\". Are you suggesting instead of\n" - "> > > using usleep_range(), using something with an even finer grain construct?\n" + "> > > I'm not sure what you mean by \"schedule()\".\302\240 Are you suggesting instead of\n" + "> > > using usleep_range(),\302\240 using something with an even finer grain construct?\n" "> > > \n" "> > > Thanks & Regards,\n" - "> > > - Nayna\n" + "> > > \302\240\302\240\302\240\302\240 - Nayna\n" "> > \n" "> > kernel/sched/core.c\n" "> \n" @@ -46,20 +46,20 @@ "> iteration?\n" "\n" "I still don't understand why scheduling some work would be an\n" - "improvement. We still need to loop, testing for the TPM command to\n" + "improvement. \302\240We still need to loop, testing for the TPM command to\n" "complete.\n" "\n" "According to the schedule_hrtimeout_range() function comment,\n" "schedule_hrtimeout_range() is both power and performance friendly.\n" - " What we didn't realize is that the hrtimer *uses* the maximum range\n" + "\302\240What we didn't realize is that the hrtimer *uses* the maximum range\n" "to calculate the sleep time, but *may* return earlier based on the\n" "minimum time.\n" "\n" - "This patch minimizes the tpm_msleep(). The subsequent patch in this\n" - "patch set shows that 1 msec isn't fine enough granularity. I still\n" + "This patch minimizes the tpm_msleep(). \302\240The subsequent patch in this\n" + "patch set shows that 1 msec isn't fine enough granularity. \302\240I still\n" "think calling usleep_range() is the right solution, but it needs to be\n" "at a finer granularity than tpm_msleep() provides.\n" "\n" Mimi -8c040c3f50aea995c8ffe29f6b4d64cdcaed99196642d544d15ac2e5880a3da6 +1b3e50b368f6772aeb20136be00c270395e1f75ec0fd525a7ef3d86171d6632b
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.