Messages in this thread | | | Date | Mon, 21 Nov 2011 22:42:29 +0530 | From | "Srivatsa S. Bhat" <> | Subject | Re: [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures |
| |
On 11/21/2011 10:17 PM, Tejun Heo wrote: > Hello, Rafael. > > On Sat, Nov 19, 2011 at 10:57:19PM +0100, Rafael J. Wysocki wrote: >>> + while (!mutex_trylock(&pm_mutex)) { >>> + try_to_freeze(); >>> + msleep(10); >> >> The number here seems to be somewhat arbitrary. Is there any reason not to >> use 100 or any other number? > > This is a bit moot at this point but, at least for me, yeah, it's a > number I pulled out of my ass. That said, I think it's a good number > to pull out of ass for userland visible retry delays for the following > reasons. > > * It's a good number - 10! which happens to match the number of > fingers I have! Isn't that just weird? @.@ > > * For modern hardware of most classes, repeating not-so-complex stuff > every 10ms for a while isn't taxing (or even noticeable) at all. > > * Sub 10ms delays usually aren't noticeable to human beings even when > several of them are staggered. This is very different when you get > to 100ms range. > > ie. going from 1ms to 10ms doesn't cost you too much in terms of human > noticeable latency (for this type of situations anyway) but going from > 10ms to 100ms does. In terms of computational cost, the reverse is > somewhat true too. So, yeah, I think 10ms is a good out-of-ass number > for this type of delays. >
My God! I had absolutely no idea you had cooked up that number just like that ;-) Look at how creative I was when defending that number :P Your justification is not bad either ;-)
[ Well, seriously, I had given a fair amount of thought before incorporating that number in my patch, by looking at the freezer re-try latency and so on, which I explained in my reply earlier.]
Anyways, nice one :-)
Thanks, Srivatsa S. Bhat
| |