public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Andrew Morton <akpm@osdl.org>, Sam Vilain <sam@vilain.net>,
	Srivatsa <vatsa@in.ibm.com>, Balbir Singh <bsingharora@gmail.com>,
	Kirill Korotaev <dev@openvz.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Mike Galbraith <efault@gmx.de>,
	Kingsley Cheung <kingsley@aurema.com>,
	CKRM <ckrm-tech@lists.sourceforge.net>,
	Ingo Molnar <mingo@elte.hu>,
	Rene Herman <rene.herman@keyaccess.nl>
Subject: Re: [PATCH 1/4] sched: Add CPU rate soft caps
Date: Sun, 18 Jun 2006 18:38:35 +1000	[thread overview]
Message-ID: <200606181838.36389.kernel@kolivas.org> (raw)
In-Reply-To: <20060618082648.6061.62247.sendpatchset@heathwren.pw.nest>

On Sunday 18 June 2006 18:26, Peter Williams wrote:
> 3. Thanks to suggestions from Con Kolivas with respect to alternative
> methods to reduce the possibility of a task being starved of CPU while
> holding an important system resource, enforcement of caps is now
> quite strict.  However, there will still be occasions where caps may be
> exceeded due to this mechanism vetoing enforcement.

I hate to do this to you again but the mutexes held count advice I gave was 
slightly off :|
>  int fastcall __sched mutex_lock_interruptible(struct mutex *lock)
>  {
> +	int ret;
> +
>  	might_sleep();
> -	return __mutex_fastpath_lock_retval
> +	ret = __mutex_fastpath_lock_retval
>  			(&lock->count, __mutex_lock_interruptible_slowpath);
> +
> +	if (!ret)
> +		inc_mutex_count();
> +
> +	return ret;
>  }
>
>  EXPORT_SYMBOL(mutex_lock_interruptible);
> @@ -357,8 +381,13 @@ static inline int __mutex_trylock_slowpa
>   */
>  int fastcall __sched mutex_trylock(struct mutex *lock)
>  {
> -	return __mutex_fastpath_trylock(&lock->count,
> +	int ret = __mutex_fastpath_trylock(&lock->count,
>  					__mutex_trylock_slowpath);
> +
> +	if (!ret)
> +		inc_mutex_count();
> +
> +	return ret;

See my track-mutexes-1.patch I recently posted.

 int fastcall __sched mutex_lock_interruptible(struct mutex *lock)
 {
+	int ret;
+
 	might_sleep();
-	return __mutex_fastpath_lock_retval
+	ret = __mutex_fastpath_lock_retval
 			(&lock->count, __mutex_lock_interruptible_slowpath);
+	if (likely(!ret))
+		inc_mutex_count();
+	return ret;
 }
 
 EXPORT_SYMBOL(mutex_lock_interruptible);
@@ -308,8 +325,12 @@ static inline int __mutex_trylock_slowpa
  */
 int fastcall mutex_trylock(struct mutex *lock)
 {
-	return __mutex_fastpath_trylock(&lock->count,
+	int ret = __mutex_fastpath_trylock(&lock->count,
 					__mutex_trylock_slowpath);
+
+	if (likely(ret))
+		inc_mutex_count();
+	return ret;
 }

Note the if !ret in mutex_lock_interruptible vs the if ret in mutex_trylock(

I really should have given you the original debugging code that went with it, 
sorry.

-- 
-ck

  reply	other threads:[~2006-06-18  8:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-18  8:26 [PATCH 0/4] sched: Add CPU rate caps Peter Williams
2006-06-18  8:26 ` [PATCH 1/4] sched: Add CPU rate soft caps Peter Williams
2006-06-18  8:38   ` Con Kolivas [this message]
2006-06-18 15:52     ` Peter Williams
2006-06-19  1:21   ` Peter Williams
2006-06-18  8:26 ` [PATCH 2/4] sched: Add CPU rate hard caps Peter Williams
2006-06-18  8:27 ` [PATCH 3/4] sched: Add procfs interface for CPU rate soft caps Peter Williams
2006-06-18  8:27 ` [PATCH 4/4] sched: Add procfs interface for CPU rate hard caps Peter Williams
2006-06-18  9:50 ` [PATCH 0/4] sched: Add CPU rate caps Andrew Morton
2006-06-18 10:25   ` Peter Williams
2006-06-18 11:42     ` Srivatsa Vaddagiri
2006-06-18 12:19       ` Peter Williams
2006-06-19  0:13     ` Balbir Singh
2006-06-19  1:03       ` [ckrm-tech] " Peter Williams
2006-06-19  2:20         ` Balbir Singh
2006-06-19  3:17           ` Peter Williams
2006-06-19  3:31             ` Balbir Singh
2006-06-19  3:50               ` Peter Williams
2006-06-19  8:30                 ` Balbir Singh
2006-06-19 11:35                   ` Peter Williams
2006-06-19 11:33                     ` Balbir Singh
2006-06-19 23:09                       ` Peter Williams
2006-06-20  4:28           ` Peter Williams
2006-06-20  4:40             ` Balbir Singh
2006-06-20  5:56               ` Peter Williams
2006-06-19  5:04     ` Peter Williams
2006-06-19 23:59   ` Peter Williams
2006-06-19 18:55 ` [ckrm-tech] " Chris Friesen
2006-06-19 23:28   ` Peter Williams
  -- strict thread matches above, loose matches on Subject: below --
2006-06-22  1:52 Peter Williams
2006-06-22  1:52 ` [PATCH 1/4] sched: Add CPU rate soft caps Peter Williams

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=200606181838.36389.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@osdl.org \
    --cc=bsingharora@gmail.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=dev@openvz.org \
    --cc=efault@gmx.de \
    --cc=kingsley@aurema.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pwil3058@bigpond.net.au \
    --cc=rene.herman@keyaccess.nl \
    --cc=sam@vilain.net \
    --cc=vatsa@in.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox