All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	pavel@ucw.cz, lenb@kernel.org, ak@linux.intel.com,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures
Date: Mon, 21 Nov 2011 22:42:29 +0530	[thread overview]
Message-ID: <4ECA867D.4050901@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111121164758.GC15314@google.com>

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	pavel@ucw.cz, lenb@kernel.org, ak@linux.intel.com,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures
Date: Mon, 21 Nov 2011 22:42:29 +0530	[thread overview]
Message-ID: <4ECA867D.4050901@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111121164758.GC15314@google.com>

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


  reply	other threads:[~2011-11-21 17:12 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17  8:30 [PATCH v3] PM/Memory-hotplug: Avoid task freezing failures Srivatsa S. Bhat
2011-11-17  8:30 ` Srivatsa S. Bhat
2011-11-19 18:32 ` Tejun Heo
2011-11-19 18:32   ` Tejun Heo
2011-11-19 19:35   ` Srivatsa S. Bhat
2011-11-19 19:35     ` Srivatsa S. Bhat
2011-11-19 21:57 ` Rafael J. Wysocki
2011-11-19 21:57   ` Rafael J. Wysocki
2011-11-20  6:03   ` Srivatsa S. Bhat
2011-11-20  6:03     ` Srivatsa S. Bhat
2011-11-20 10:24     ` Rafael J. Wysocki
2011-11-20 10:24       ` Rafael J. Wysocki
2011-11-21  4:36       ` Srivatsa S. Bhat
2011-11-21  4:36         ` Srivatsa S. Bhat
2011-11-21  7:55         ` Chen Gong
2011-11-21  7:55           ` Chen Gong
2011-11-21  8:22           ` Srivatsa S. Bhat
2011-11-21  8:22             ` Srivatsa S. Bhat
2011-11-21 16:40         ` Tejun Heo
2011-11-21 16:40           ` Tejun Heo
2011-11-21 17:04           ` Srivatsa S. Bhat
2011-11-21 17:04             ` Srivatsa S. Bhat
2011-11-21 17:52             ` Tejun Heo
2011-11-21 17:52               ` Tejun Heo
2011-11-21 18:01               ` Srivatsa S. Bhat
2011-11-21 18:01                 ` Srivatsa S. Bhat
2011-11-21 20:05                 ` Rafael J. Wysocki
2011-11-21 20:05                   ` Rafael J. Wysocki
2011-11-21 18:12             ` [PATCH v4] PM / Memory-hotplug: " Srivatsa S. Bhat
2011-11-21 18:12               ` Srivatsa S. Bhat
2011-11-21 18:23               ` Tejun Heo
2011-11-21 18:23                 ` Tejun Heo
2011-11-21 18:25                 ` Srivatsa S. Bhat
2011-11-21 18:25                   ` Srivatsa S. Bhat
2011-11-21 22:41                 ` Rafael J. Wysocki
2011-11-21 22:41                   ` Rafael J. Wysocki
2011-11-21 16:47   ` [PATCH v3] PM/Memory-hotplug: " Tejun Heo
2011-11-21 16:47     ` Tejun Heo
2011-11-21 17:12     ` Srivatsa S. Bhat [this message]
2011-11-21 17:12       ` Srivatsa S. Bhat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ECA867D.4050901@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=ak@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.