On 14/02/2019 20:25, Dan Williams wrote:
> On Thu, Feb 14, 2019 at 5:46 AM Michal Hocko wrote:
>>
>> On Wed 06-02-19 13:12:59, Dan Williams wrote:
>> [...]
>>> * Userfaultfd for file-backed mappings and DAX
>>
>> I assume that other topics are meant to be FS track but this one is MM,
>> right?
>
On 05/08/2019 21:49, Vivek Goyal wrote:
> On Mon, Aug 05, 2019 at 02:53:06PM +0300, Boaz Harrosh wrote:
<>
>> So as I understand the man page:
>> fallocate(FL_PUNCH_HOLE); means user is asking to get rid also of COW pages.
>> On the other way fallocate(FL_ZERO_RANG
On 02/08/2019 22:37, Dan Williams wrote:
> On Fri, Aug 2, 2019 at 12:30 PM Vivek Goyal wrote:
>>
>> As of now dax_layout_busy_page() calls unmap_mapping_range() with last
>> argument as 1, which says even unmap cow pages. I am wondering who needs
>> to get rid of cow pages as well.
>>
>> I noticed
On 04/07/2019 16:58, Matthew Wilcox wrote:
> On Thu, Jul 04, 2019 at 04:00:00PM +0300, Boaz Harrosh wrote:
<>
>> Matthew you must be kidding an ilog2 in binary is zero clocks
>> (Return the highest bit or something like that)
>
> You might want to actually check the do
On 04/07/2019 06:27, Matthew Wilcox wrote:
> On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote:
<>
>>> +#ifdef CONFIG_XARRAY_MULTI
>>> + unsigned int sibs = xas->xa_sibs;
>>> +
>>> + while (sibs) {
>>> + order++;
>>> + sibs /= 2;
>>> + }
>>
>
On 03/07/2019 03:42, Dan Williams wrote:
> On Tue, Jul 2, 2019 at 5:23 PM Boaz Harrosh wrote:
<>
>
> Yes, but the trick is how to manage cases where someone waiting on one
> type needs to be woken up by an event on the other.
Exactly I'm totally with you on this.
>
On 02/07/2019 18:37, Dan Williams wrote:
<>
>
> I'd be inclined to do the brute force fix of not trying to get fancy
> with separate PTE/PMD waitqueues and then follow on with a more clever
> performance enhancement later. Thoughts about that?
>
Sir Dan
I do not understand how separate waitqueu
In Patch:
[7a862fb] brd: remove dax support
Dan Williams has removed the only might_sleep
implementation of ->direct_access.
So we no longer need to check for it.
CC: Dan Williams
Signed-off-by: Boaz Harrosh
---
drivers/dax/super.c | 6 --
1 file changed, 6 deleti
On 15/08/17 12:06, Boaz Harrosh wrote:
> On 14/08/17 19:03, Dan Williams wrote:
>> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh wrote:
>>>
>>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked
>>> for
>>&
On 14/08/17 19:03, Dan Williams wrote:
> On Mon, Aug 14, 2017 at 7:04 AM, Boaz Harrosh wrote:
>>
>> Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for
>> it in 2014. I'm so glad its time is finally do.
>>
<>
>> 4] On
Thank you Jan, I'm patiently waiting for this MAP_SYNC flag since I asked for
it in 2014. I'm so glad its time is finally do.
Thank you for working on this. Please CC me on future patches.
(note the new Netapp email)
On 13/08/17 12:25, Christoph Hellwig wrote:
> On Sat, Aug 12, 2017 at 07:44:14P
he backing device was released.
>
> Signed-off-by: Logan Gunthorpe
Cool thanks. And even a bug fix
ACK-by: Boaz Harrosh
> ---
> drivers/scsi/osd/osd_uld.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/osd/osd_uld.c b/driv
On 02/16/2017 09:35 PM, Dan Williams wrote:
> On Thu, Feb 16, 2017 at 10:51 AM, Linda Knippers
> wrote:
<>
>> True, but configuring boot options and a reboot are required.
>
> Module options are specified at module load time so you don't
> necessarily need a reboot. However, I'm now of the opini
On 10/28/2016 04:54 AM, Boylston, Brian wrote:
> Boaz Harrosh wrote on 2016-10-26:
>> On 10/26/2016 06:50 PM, Brian Boylston wrote:
>>> Introduce memcpy_nocache() as a memcpy() that avoids the processor cache
>>> if possible. Without arch-specific support, this defaults
On 10/26/2016 06:50 PM, Brian Boylston wrote:
> copy_from_iter_nocache() now uses nocache copies for all types of iovecs
> on x86, so the flush in arch_copy_from_iter_pmem() is no longer needed.
>
> Cc: Ross Zwisler
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc:
> Cc: Al
On 10/26/2016 06:50 PM, Brian Boylston wrote:
> Introduce memcpy_nocache() as a memcpy() that avoids the processor cache
> if possible. Without arch-specific support, this defaults to just
> memcpy(). For now, include arch-specific support for x86.
>
> Cc: Ross Zwisler
> Cc: Thomas Gleixner
>
On 08/19/2016 09:30 PM, Ross Zwisler wrote:
> On Fri, Aug 19, 2016 at 07:59:29AM -0700, Dan Williams wrote:
>> On Fri, Aug 19, 2016 at 4:19 AM, Xiao Guangrong
>> wrote:
>>>
>>> Hi Dan,
>>>
>>> Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
>>> more detailed info please refer to
On 07/30/2016 03:12 AM, Dave Chinner wrote:
<>
>
> If we track the dirty blocks from write in the radix tree like we
> for mmap, then we can just use a normal memcpy() in dax_do_io(),
> getting rid of the slow cache bypass that is currently run. Radix
> tree updates are much less expensive than a
On 06/28/2016 06:39 PM, Christoph Hellwig wrote:
> On Tue, Jun 28, 2016 at 04:56:30PM +0300, Boaz Harrosh wrote:
>> Actually with O_APPEND each write request should write a different region
>> of the file, there are no overlapping writes. And no issue of which version
>> of t
On 06/28/2016 04:39 PM, Christoph Hellwig wrote:
> On Tue, Jun 28, 2016 at 04:27:03PM +0300, Boaz Harrosh wrote:
>>> Right. And an existing application can get DAX turned on under its
>>> back, and will now suddently get different synchronization behavior.
>>> That
On 06/28/2016 04:10 PM, Christoph Hellwig wrote:
> On Sat, Jun 25, 2016 at 09:00:45AM +1000, Dave Chinner wrote:
<>
>
> Right. And an existing application can get DAX turned on under its
> back, and will now suddently get different synchronization behavior.
> That is if it's writes happen to be a
On 06/22/2016 06:27 PM, Christoph Hellwig wrote:
> So far DAX writes inherited the locking from direct I/O writes, but the direct
> I/O model of using shared locks for writes is actually wrong for DAX. For
> direct I/O we're out of any standards and don't have to provide the Posix
> required exclu
with this patch for a while in the lab and it does
solve the problem above with no maleffects so:
Tested-by: Boaz Harrosh
> Signed-off-by: Yigal Korman
> ---
> arch/x86/kernel/e820.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/e
23 matches
Mail list logo
