From: NeilBrown <neilb@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 3/3] radix-tree: support locking of individual exception entries.
Date: Fri, 04 Mar 2016 21:14:24 +1100 [thread overview]
Message-ID: <87si06lfcv.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <87a8mfm86l.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Fri, Mar 04 2016, NeilBrown wrote:
>
> By not layering on top of wait_bit_key, you've precluded the use of the
> current page wait_queues for these locks - you need to allocate new wait
> queue heads.
>
> If in
>
>> +struct wait_exceptional_entry_queue {
>> + wait_queue_t wait;
>> + struct exceptional_entry_key key;
>> +};
>
> you had the exceptional_entry_key first (like wait_bit_queue does) you
> would be closer to being able to re-use the queues.
Scratch that bit, I was confusing myself again. Sorry.
Each wait_queue_t has it's own function so one function will never be
called on other items in the queue - of course.
>
> Also I don't think it is safe to use an exclusive wait. When a slot is
> deleted, you need to wake up *all* the waiters.
I think this issue is still valid.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 3/3] radix-tree: support locking of individual exception entries.
Date: Fri, 04 Mar 2016 21:14:24 +1100 [thread overview]
Message-ID: <87si06lfcv.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <87a8mfm86l.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Fri, Mar 04 2016, NeilBrown wrote:
>
> By not layering on top of wait_bit_key, you've precluded the use of the
> current page wait_queues for these locks - you need to allocate new wait
> queue heads.
>
> If in
>
>> +struct wait_exceptional_entry_queue {
>> + wait_queue_t wait;
>> + struct exceptional_entry_key key;
>> +};
>
> you had the exceptional_entry_key first (like wait_bit_queue does) you
> would be closer to being able to re-use the queues.
Scratch that bit, I was confusing myself again. Sorry.
Each wait_queue_t has it's own function so one function will never be
called on other items in the queue - of course.
>
> Also I don't think it is safe to use an exclusive wait. When a slot is
> deleted, you need to wake up *all* the waiters.
I think this issue is still valid.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2016-03-04 10:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-28 5:09 [PATCH 0/3] RFC improvements to radix-tree related to DAX NeilBrown
2016-02-28 5:09 ` NeilBrown
2016-02-28 5:09 ` [PATCH 1/3] DAX: move RADIX_DAX_ definitions to dax.c NeilBrown
2016-02-28 5:09 ` NeilBrown
2016-02-29 14:28 ` Wilcox, Matthew R
2016-02-29 17:46 ` Ross Zwisler
2016-02-29 17:46 ` Ross Zwisler
2016-02-28 5:09 ` [PATCH 2/3] radix-tree: make 'indirect' bit available to exception entries NeilBrown
2016-02-28 5:09 ` NeilBrown
2016-02-29 14:41 ` Wilcox, Matthew R
2016-02-29 14:41 ` Wilcox, Matthew R
2016-03-01 21:59 ` Ross Zwisler
2016-03-01 21:59 ` Ross Zwisler
2016-02-28 5:09 ` [PATCH 3/3] radix-tree: support locking of individual " NeilBrown
2016-02-28 5:09 ` NeilBrown
2016-02-28 5:30 ` kbuild test robot
2016-02-28 6:27 ` NeilBrown
2016-03-03 13:10 ` Jan Kara
2016-03-03 13:10 ` Jan Kara
2016-03-03 23:51 ` NeilBrown
2016-03-03 23:51 ` NeilBrown
2016-03-04 10:14 ` NeilBrown [this message]
2016-03-04 10:14 ` NeilBrown
2016-03-04 12:31 ` Jan Kara
2016-03-04 12:31 ` Jan Kara
2016-03-09 2:13 ` NeilBrown
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=87si06lfcv.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.r.wilcox@intel.com \
--cc=ross.zwisler@linux.intel.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 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.