public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: zippel@linux-m68k.org, akpm@osdl.org, torvalds@osdl.org,
	Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
	nikita@clusterfs.com
Subject: Re: [PATCH] cpuset semaphore depth check optimize
Date: Tue, 13 Sep 2005 23:01:19 -0700	[thread overview]
Message-ID: <20050913230119.13be3fed.pj@sgi.com> (raw)
In-Reply-To: <20050913103724.19ac5efa.pj@sgi.com>

pj wrote:
> I'd expect the spinlocks to get taken
> and released in the following order on these cpusets:
> 
> 	    lock /A/B/C
> 	    lock /A/B
> 	    lock /A
> 	    lock /
> 	      ==> found what I was searching for
> 	    unlock /
> 	    unlock /A
> 	    unlock /A/B
> 	    unlock /A/B/C

The appropriate condition required to prevent deadlock is weaker than
stated above.  The condition should be:

     * A task can hold the spinlocks for multiple cpusets, but only
     * if it acquires in bottom up order.  That is, whenever a task
     * tries to lock a cpuset, the only cpusets it may already have
     * locked must be descendents of the one it is going for.

With this, the following sequence of lock operations would also
be acceptable, holding the bottom lock, while walking up the tree,
locking and unlocking each ancestor in turn, until one is found
that satisfies the present query.  Only the bottom most lock has
to be held in this approach, for the duration.

 	    lock /A/B/C
 	    lock /A/B
 	    unlock /A/B
 	    lock /A
 	    unlock /A
 	    lock /
 	      ==> found what I was searching for
 	    unlock /
 	    unlock /A/B/C

This sequence is a little easier to implement, because there is no need
to keep a variable length queue of locks to be undone.  At most two
locks are held at anytime.

If a variable length queue of locks to be undone had been needed, it
could have been implemented using one more field in each cpuset,
forming a LIFO linked list of cpusets to be unlocked.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2005-09-14  6:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 11:30 [PATCH] cpuset semaphore depth check optimize Paul Jackson
2005-09-12 11:39 ` Andrew Morton
2005-09-12 14:38   ` Linus Torvalds
2005-09-12 15:32     ` Paul Jackson
     [not found]     ` <17189.39100.862561.865802@gargle.gargle.HOWL>
2005-09-12 15:38       ` Paul Jackson
2005-09-13  7:04     ` Ingo Molnar
2005-09-13 22:21       ` Paul Jackson
2005-09-12 14:51   ` Paul Jackson
2005-09-12 17:07     ` Roman Zippel
     [not found]       ` <20050912153135.3812d8e2.pj@sgi.com>
2005-09-13 11:42         ` Roman Zippel
2005-09-13 17:37           ` Paul Jackson
2005-09-14  6:01             ` Paul Jackson [this message]
2005-09-14 15:56             ` Roman Zippel
2005-09-14 19:46               ` Paul Jackson
2005-09-15 10:51                 ` Roman Zippel
2005-09-15 17:45                   ` Paul Jackson
2005-09-15 19:18                     ` Paul Jackson
2005-09-17  2:06                     ` Roman Zippel
2005-09-17  2:27                       ` Roman Zippel
2005-09-20  7:57                     ` Paul Jackson
2005-09-20 12:05                       ` Robin Holt
2005-09-20 12:21                         ` Robin Holt
2005-09-20 13:10                         ` Simon Derr
2005-09-20 14:22                         ` Paul Jackson
2005-09-20 14:54                           ` Robin Holt
2005-09-20 15:07                             ` Linus Torvalds
2005-09-20 15:14                             ` Paul Jackson
2005-09-20 15:17                             ` Simon Derr
2005-09-12 11:48 ` Nikita Danilov
2005-09-12 13:25   ` Paul Jackson

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=20050913230119.13be3fed.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita@clusterfs.com \
    --cc=torvalds@osdl.org \
    --cc=zippel@linux-m68k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox