public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	James Bottomley <James.Bottomley@SteelEye.com>,
	Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] make radix tree gang lookup faster by using a bitmap search
Date: Mon, 29 Aug 2005 09:16:41 -0400	[thread overview]
Message-ID: <43130AB9.3080805@adaptec.com> (raw)
In-Reply-To: <1125287651.29493.3.camel@lade.trondhjem.org>

On 08/28/05 23:54, Trond Myklebust wrote:
> må den 29.08.2005 Klokka 13:37 (+1000) skreiv Nick Piggin:
> 
>>James Bottomley wrote:
>>
>>>On Sun, 2005-08-28 at 18:35 -0700, Andrew Morton wrote:
>>
>>>>It does make the tree higher and hence will incur some more cache missing
>>>>when descending the tree.
>>>
>>>
>>>Actually, I don't think it does:  the common user is the page tree.
>>>Obviously, I've changed nothing on 64 bits, so we only need to consider
>>>what I've done on 32 bits.  A page size is almost universally 4k on 32
>>>bit, so we need 20 bits to store the page tree index.  Regardless of
>>>whether the index size is 5 or 6, that gives a radix tree depth of 4.
>>>
>>
>>s/common/only ?
> 
> 
> grep again... I use it in the NFS client for bookkeeping requests.

Hey guys,

Take the posix-timers for example:

idr_remove() is called with spin_lock_irqsave()/spin_unlock_irqrestore(),
in release_posix_timer().

_But_, idr_pre_get() is called without any locks (as it should) which
calls alloc_layer() in the IDR code, grabbing a spinlock _internally_ (no IRQ).

If you're in the middle of idr_pre_get() inside the internally locked
section of alloc_layer(), _and_ you call idr_remove() at that same time
and (try to) enter free_layer(), you have a deadlock.

The reason no one has seen this is: _load_.  It wasn't until I started
doing mkfs simultaneously on 3 or more disks in a loop, that I saw this
problem.  I've a stack trace to show if anyone cares.

I'm not sure why no one sees this.

I'm also not sure why people are working on IDR when there is no
_pending_ need to improve this code (other than the deadlock I pointed out),
while SCSI Core has been in dire need of improvement for the last 5 years.

If SCSI Core developed in the same scheme as IDR is now: 
"no need, but its cool so I'll write it and my buddies will include the patch",
we would have a *T10 spec-ed out SCSI Core by now*.(1)

	Luben

(1) I can hear it now... "But do we need it?"
But do we need these IDR improvements when there is no bug report
or oops or architectural need to change it?  Other than the
deadlock?




  reply	other threads:[~2005-08-29 13:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-27 16:26 [PATCH] make radix tree gang lookup faster by using a bitmap search James Bottomley
2005-08-27 17:53 ` Andrew Morton
2005-08-28 19:43   ` James Bottomley
2005-08-28 20:00     ` Linus Torvalds
2005-08-28 20:39       ` Andrew Morton
2005-08-29  0:45   ` James Bottomley
2005-08-29  0:52     ` Andrew Morton
2005-08-29  1:19       ` James Bottomley
2005-08-29  1:35         ` Andrew Morton
2005-08-29  3:26           ` James Bottomley
2005-08-29  3:37             ` Nick Piggin
2005-08-29  3:54               ` Trond Myklebust
2005-08-29 13:16                 ` Luben Tuikov [this message]
2005-08-29 15:01               ` James Bottomley
     [not found]               ` <20050829164144.GC9508@localhost.localdomain>
2005-08-30  0:56                 ` Nick Piggin
2005-08-30  1:54                   ` Andrew Morton
2005-08-30  2:46                   ` James Bottomley
2005-08-30  2:53                     ` Nick Piggin
     [not found]                       ` <20050830052405.GB20843@localhost.localdomain>
2005-08-30 13:06                         ` Nick Piggin

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=43130AB9.3080805@adaptec.com \
    --to=luben_tuikov@adaptec.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=trond.myklebust@fys.uio.no \
    /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