Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1333461

Re: Another proposal for DAX fault locking

Show all headers | View raw

On 02/11/2016 12:38 PM, Jan Kara wrote:
> On Wed 10-02-16 19:38:21, Boaz Harrosh wrote:
>> On 02/09/2016 07:24 PM, Jan Kara wrote:
>>> Hello,
>>>
<>
>>>
>>> DAX will have an array of mutexes (the array can be made per device but
>>> initially a global one should be OK). We will use mutexes in the array as a
>>> replacement for page lock - we will use hashfn(mapping, index) to get
>>> particular mutex protecting our offset in the mapping. On fault / page
>>> mkwrite, we'll grab the mutex similarly to page lock and release it once we
>>> are done updating page tables. This deals with races in [1]. When flushing
>>> caches we grab the mutex before clearing writeable bit in page tables
>>> and clearing dirty bit in the radix tree and drop it after we have flushed
>>> caches for the pfn. This deals with races in [2].
>>>
>>> Thoughts?
>>>
>>
>> You could also use one of the radix-tree's special-bits as a bit lock.
>> So no need for any extra allocations.
> 
> Yes and I've suggested that once as well. But since we need sleeping
> locks, you need some wait queues somewhere as well. So some allocations are
> going to be needed anyway. 

They are already sleeping locks and there are all the proper "wait queues"
in place. I'm talking about
   lock:
	err = wait_on_bit_lock(&some_long, SOME_BIT_LOCK, ...);
and
   unlock:
	WARN_ON(!test_and_clear_bit(SOME_BIT_LOCK, &some_long));
	wake_up_bit(&some_long, SOME_BIT_LOCK);

> And mutexes have much better properties than

Just saying that page-locks are implemented just this way these days
so it is the performance and characteristics we already know.
(You are replacing page locks, no?)

> bit-locks so I prefer mutexes over cramming bit locks into radix tree. Plus
> you'd have to be careful so that someone doesn't remove the bit from the
> radix tree while you are working with it.
> 

Sure! need to be careful, is our middle name.

That said. Is your call. Thank you for working on this. Your plan sounds
very good as well, and is very much needed, because DAX's mmap performance
success right now.
[Maybe one small enhancement perhaps allocate an array of mutexes per NUMA
 node and access the proper array through numa_node_id()]

> 								Honza
> 

Thanks
Boaz

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-09 18:30 +0100
  Re: Another proposal for DAX fault locking Dan Williams <dan.j.williams@intel.com> - 2016-02-09 19:20 +0100
    Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-10 11:40 +0100
      Re: Another proposal for DAX fault locking Dan Williams <dan.j.williams@intel.com> - 2016-02-10 21:10 +0100
        Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-11 11:50 +0100
      Re: Another proposal for DAX fault locking Dave Chinner <david@fromorbit.com> - 2016-02-10 23:20 +0100
        Re: Another proposal for DAX fault locking Cedric Blancher <cedric.blancher@gmail.com> - 2016-02-10 23:40 +0100
          Re: Another proposal for DAX fault locking Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-11 00:40 +0100
          Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-11 12:00 +0100
            Re: Another proposal for DAX fault locking Cedric Blancher <cedric.blancher@gmail.com> - 2016-02-11 22:10 +0100
        Re: Another proposal for DAX fault locking Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-11 00:40 +0100
          Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-11 12:20 +0100
  Re: Another proposal for DAX fault locking Cedric Blancher <cedric.blancher@gmail.com> - 2016-02-09 19:50 +0100
    Re: Another proposal for DAX fault locking Mel Gorman <mgorman@suse.de> - 2016-02-10 09:20 +0100
      Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-10 11:20 +0100
  Re: Another proposal for DAX fault locking Dmitry Monakhov <dmonlist@gmail.com> - 2016-02-10 13:40 +0100
    Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-10 13:40 +0100
  Re: Another proposal for DAX fault locking Boaz Harrosh <boaz@plexistor.com> - 2016-02-10 18:40 +0100
    Re: Another proposal for DAX fault locking Jan Kara <jack@suse.cz> - 2016-02-11 11:40 +0100
      Re: Another proposal for DAX fault locking Boaz Harrosh <openosd@gmail.com> - 2016-02-14 10:00 +0100
  Re: Another proposal for DAX fault locking Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-11 00:50 +0100
    Re: Another proposal for DAX fault locking Cedric Blancher <cedric.blancher@gmail.com> - 2016-02-11 01:00 +0100
      Re: Another proposal for DAX fault locking Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-11 01:20 +0100

csiph-web