Re: Another proposal for DAX fault locking

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

Re: Another proposal for DAX fault locking

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

Re: Another proposal for DAX fault locking

The Solaris 11 sources are still available at Illumos.org (Illumos is what Opensolaris was once, minus Suns bug database). Also, if you keep the performance in mind, remember that the world is moving towards many cores with many hardware threads per core, so optimising for the "two core with low

Re: Another proposal for DAX fault locking

On Wed 10-02-16 16:32:53, Ross Zwisler wrote: > On Thu, Feb 11, 2016 at 09:09:53AM +1100, Dave Chinner wrote: > > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > > > > Hello,

Re: Another proposal for DAX fault locking

On Wed 10-02-16 23:39:43, Cedric Blancher wrote: > AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the > scalability problem AND deals with variable page size. Well, but then you have to have this locking tree for every inode so the memory overhead is relatively large, no? I've

Re: Another proposal for DAX fault locking

On Wed 10-02-16 12:08:12, Dan Williams wrote: > On Wed, Feb 10, 2016 at 2:32 AM, Jan Kara wrote: > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > >> On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > >> > Hello, > >> > > >> > I was thinking about current issues with DAX fault locking [1] (data

Re: Another proposal for DAX fault locking

On Wed 10-02-16 19:38:21, Boaz Harrosh wrote: > On 02/09/2016 07:24 PM, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't allow us to clear dirty

Re: Another proposal for DAX fault locking

On Wed 10-02-16 23:39:43, Cedric Blancher wrote: > AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the > scalability problem AND deals with variable page size. Well, but then you have to have this locking tree for every inode so the memory overhead is relatively large, no? I've

Re: Another proposal for DAX fault locking

On Wed 10-02-16 16:32:53, Ross Zwisler wrote: > On Thu, Feb 11, 2016 at 09:09:53AM +1100, Dave Chinner wrote: > > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > >

Re: Another proposal for DAX fault locking

On Wed 10-02-16 12:08:12, Dan Williams wrote: > On Wed, Feb 10, 2016 at 2:32 AM, Jan Kara wrote: > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > >> On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > >> > Hello, > >> > > >> > I was thinking about current issues with

Re: Another proposal for DAX fault locking

On Wed 10-02-16 19:38:21, Boaz Harrosh wrote: > On 02/09/2016 07:24 PM, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't allow us to clear dirty

Re: Another proposal for DAX fault locking

The Solaris 11 sources are still available at Illumos.org (Illumos is what Opensolaris was once, minus Suns bug database). Also, if you keep the performance in mind, remember that the world is moving towards many cores with many hardware threads per core, so optimising for the "two core with low

Re: Another proposal for DAX fault locking

On Thu, Feb 11, 2016 at 12:51:05AM +0100, Cedric Blancher wrote: > There is another "twist" in this game: If there is a huge page with > 1GB with a small 4k page as "overlay" (e.g. mmap() MAP_FIXED somewhere > in the middle of a 1GB huge page), hows that handled? Ugh - I'm pretty sure we haven't

Re: Another proposal for DAX fault locking

There is another "twist" in this game: If there is a huge page with 1GB with a small 4k page as "overlay" (e.g. mmap() MAP_FIXED somewhere in the middle of a 1GB huge page), hows that handled? Ced On 11 February 2016 at 00:44, Ross Zwisler wrote: > On Tue, Feb 09, 2016 at 06:24:16PM +0100, Jan

Re: Another proposal for DAX fault locking

On Tue, Feb 09, 2016 at 06:24:16PM +0100, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races >

Re: Another proposal for DAX fault locking

On Thu, Feb 11, 2016 at 09:09:53AM +1100, Dave Chinner wrote: > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > > > Hello, > > > > > > > > I was thinking about current issues with

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 11:39:43PM +0100, Cedric Blancher wrote: > AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the > scalability problem AND deals with variable page size. Right - seems like tying the radix tree into the locking instead of using an array would have these same

Re: Another proposal for DAX fault locking

AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the scalability problem AND deals with variable page size. Ced On 10 February 2016 at 23:09, Dave Chinner wrote: > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: >> On Tue 09-02-16 10:18:53, Dan Williams wrote: >> > On

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > > Hello, > > > > > > I was thinking about current issues with DAX fault locking [1] (data > > > corruption due to racing faults

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 2:32 AM, Jan Kara wrote: > On Tue 09-02-16 10:18:53, Dan Williams wrote: >> On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: >> > Hello, >> > >> > I was thinking about current issues with DAX fault locking [1] (data >> > corruption due to racing faults allocating blocks)

Re: Another proposal for DAX fault locking

On 02/09/2016 07:24 PM, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between faults and

Re: Another proposal for DAX fault locking

On Wed 10-02-16 15:29:34, Dmitry Monakhov wrote: > Jan Kara writes: > > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't allow us to clear dirty tags in the radix

Re: Another proposal for DAX fault locking

Jan Kara writes: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between faults and cache flushing [2]. Both

Re: Another proposal for DAX fault locking

On Tue 09-02-16 10:18:53, Dan Williams wrote: > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't allow us to clear

Re: Another proposal for DAX fault locking

On Wed 10-02-16 08:19:22, Mel Gorman wrote: > On Tue, Feb 09, 2016 at 07:46:05PM +0100, Cedric Blancher wrote: > > On 9 February 2016 at 18:24, Jan Kara wrote: > > > Hello, > > > > > > I was thinking about current issues with DAX fault locking [1] (data > > > corruption due to racing faults

Re: Another proposal for DAX fault locking

On Tue, Feb 09, 2016 at 07:46:05PM +0100, Cedric Blancher wrote: > On 9 February 2016 at 18:24, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't

Re: Another proposal for DAX fault locking

On 02/09/2016 07:24 PM, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between faults and

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 2:32 AM, Jan Kara wrote: > On Tue 09-02-16 10:18:53, Dan Williams wrote: >> On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: >> > Hello, >> > >> > I was thinking about current issues with DAX fault locking [1] (data >> > corruption due to racing

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > > Hello, > > > > > > I was thinking about current issues with DAX fault locking [1] (data > > > corruption due to racing

Re: Another proposal for DAX fault locking

AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the scalability problem AND deals with variable page size. Ced On 10 February 2016 at 23:09, Dave Chinner wrote: > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: >> On Tue 09-02-16 10:18:53, Dan

Re: Another proposal for DAX fault locking

On Wed 10-02-16 08:19:22, Mel Gorman wrote: > On Tue, Feb 09, 2016 at 07:46:05PM +0100, Cedric Blancher wrote: > > On 9 February 2016 at 18:24, Jan Kara wrote: > > > Hello, > > > > > > I was thinking about current issues with DAX fault locking [1] (data > > > corruption due to

Re: Another proposal for DAX fault locking

On Tue 09-02-16 10:18:53, Dan Williams wrote: > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't

Re: Another proposal for DAX fault locking

On Tue, Feb 09, 2016 at 07:46:05PM +0100, Cedric Blancher wrote: > On 9 February 2016 at 18:24, Jan Kara wrote: > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > >

Re: Another proposal for DAX fault locking

On Wed 10-02-16 15:29:34, Dmitry Monakhov wrote: > Jan Kara writes: > > > Hello, > > > > I was thinking about current issues with DAX fault locking [1] (data > > corruption due to racing faults allocating blocks) and also races which > > currently don't allow us to clear dirty tags

Re: Another proposal for DAX fault locking

Jan Kara writes: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between faults and cache

Re: Another proposal for DAX fault locking

There is another "twist" in this game: If there is a huge page with 1GB with a small 4k page as "overlay" (e.g. mmap() MAP_FIXED somewhere in the middle of a 1GB huge page), hows that handled? Ced On 11 February 2016 at 00:44, Ross Zwisler wrote: > On Tue, Feb 09,

Re: Another proposal for DAX fault locking

On Tue, Feb 09, 2016 at 06:24:16PM +0100, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races >

Re: Another proposal for DAX fault locking

On Wed, Feb 10, 2016 at 11:39:43PM +0100, Cedric Blancher wrote: > AFAIK Solaris 11 uses a sparse tree instead of a array. Solves the > scalability problem AND deals with variable page size. Right - seems like tying the radix tree into the locking instead of using an array would have these same

Re: Another proposal for DAX fault locking

On Thu, Feb 11, 2016 at 09:09:53AM +1100, Dave Chinner wrote: > On Wed, Feb 10, 2016 at 11:32:49AM +0100, Jan Kara wrote: > > On Tue 09-02-16 10:18:53, Dan Williams wrote: > > > On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > > > > Hello, > > > > > > > > I was thinking about

Re: Another proposal for DAX fault locking

On Thu, Feb 11, 2016 at 12:51:05AM +0100, Cedric Blancher wrote: > There is another "twist" in this game: If there is a huge page with > 1GB with a small 4k page as "overlay" (e.g. mmap() MAP_FIXED somewhere > in the middle of a 1GB huge page), hows that handled? Ugh - I'm pretty sure we haven't

Re: Another proposal for DAX fault locking

On 9 February 2016 at 18:24, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between faults

Re: Another proposal for DAX fault locking

I l On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races > between

Another proposal for DAX fault locking

Hello, I was thinking about current issues with DAX fault locking [1] (data corruption due to racing faults allocating blocks) and also races which currently don't allow us to clear dirty tags in the radix tree due to races between faults and cache flushing [2]. Both of these exist because we

Re: Another proposal for DAX fault locking

On 9 February 2016 at 18:24, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to races >

Another proposal for DAX fault locking

Hello, I was thinking about current issues with DAX fault locking [1] (data corruption due to racing faults allocating blocks) and also races which currently don't allow us to clear dirty tags in the radix tree due to races between faults and cache flushing [2]. Both of these exist because we

Re: Another proposal for DAX fault locking

I l On Tue, Feb 9, 2016 at 9:24 AM, Jan Kara wrote: > Hello, > > I was thinking about current issues with DAX fault locking [1] (data > corruption due to racing faults allocating blocks) and also races which > currently don't allow us to clear dirty tags in the radix tree due to