On 17/09/2020 15:48, Matthew Wilcox wrote:
On Thu, Sep 17, 2020 at 02:01:33PM +0200, Oleg Nesterov wrote:
<>
If we change bio_endio to invoke the ->bi_end_io callbacks in softirq
context instead of hardirq context, we can change the pagecache to take
BH-safe locks instead of IRQ-safe locks. I
On 16/09/2020 15:32, Hou Tao wrote:
<>
However the performance degradation is huge under aarch64 (4 sockets, 24 core
per sockets): nearly 60% lost.
v4.19.111
no writer, reader cn | 24| 48| 72
| 96
the rate of down_read/up_read per second
On 22/10/2019 14:21, Boaz Harrosh wrote:
> On 20/10/2019 18:59, ira.we...@intel.com wrote:
<>
>> At LSF/MM we discussed the difficulties of switching the mode of a file with
>> active mappings / page cache. Rather than solve those races the decision was
>> to
>>
On 20/10/2019 18:59, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> In order for users to determine if a file is currently operating in DAX
> mode (effective DAX). Define a statx attribute value and set that
> attribute if the effective DAX flag is set.
>
> To go along with this we propose th
On 20/10/2019 18:59, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> At LSF/MM'19 [1] [2] we discussed applications that overestimate memory
> consumption due to their inability to detect whether the kernel will
> instantiate page cache for a file, and cases where a global dax enable via a
> mou
On 06/07/2019 02:31, Dave Chinner wrote:
>
> As long as the IO ranges to the same file *don't overlap*, it should
> be perfectly safe to take separate range locks (in read or write
> mode) on either side of the mmap_sem as non-overlapping range locks
> can be nested and will not self-deadlock.
>
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 20:21, Jan Kara wrote:
> On Wed 03-07-19 04:04:57, Boaz Harrosh wrote:
>> On 19/06/2019 11:21, Jan Kara wrote:
>> <>
<>
>> Hi Jan
>>
>> Funny I'm sitting on the same patch since LSF last. I need it too for other
>> reasons.
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 03/07/2019 04:07, Patrick Farrell wrote:
> Recursively read locking is generally unsafe, that’s why lockdep
> complains about it. The common RW lock primitives are queued in
> their implementation, meaning this recursive read lock sequence:
> P1 - read (gets lock)
> P2 - write
> P1 - read
>
>
Honza
>
Hi Jan
Funny I'm sitting on the same patch since LSF last. I need it too for other
reasons. I have not seen, have you pushed your patch yet?
(Is based on old v4.20)
~
>From fddb38169e33d23060ddd444ba6f2319f76edc89 Mon Sep 17 00:00:00 2001
From: Boaz Harrosh
On 20/06/2019 01:37, Dave Chinner wrote:
<>
>
> I'd prefer it doesn't get lifted to the VFS because I'm planning on
> getting rid of it in XFS with range locks. i.e. the XFS_MMAPLOCK is
> likely to go away in the near term because a range lock can be
> taken on either side of the mmap_sem in the p
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
port it myself, til now you guys
> been doing this for me ;-)"
>
> Now the last time this caused a bit of a stir, but still no actual users,
> not even for SG_IO passthrough commands. So here we go again, this time
> including removing everything in the scsi and block layer s
On 20/12/18 09:26, Christoph Hellwig wrote:
> On Wed, Dec 19, 2018 at 09:01:53PM -0500, Douglas Gilbert wrote:
>>> 1) reduce the size of every kernel with block layer support, and
>>> even more for every kernel with scsi support
>>
>> By proposing the removal of bidi support from the block l
On 19/12/18 16:43, Christoph Hellwig wrote:
> On Mon, Nov 26, 2018 at 07:11:10PM +0200, Boaz Harrosh wrote:
>> On 11/11/18 15:32, Christoph Hellwig wrote:
>>> The only real user of the T10 OSD protocol, the pNFS object layout
>>> driver never went to the point of havin
On 28/11/18 06:32, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
ACK-by: Boaz Harrosh
> ---
> drivers/scsi/osd/osd_initiator.c | 3 ++-
&g
On 11/11/18 15:32, Christoph Hellwig wrote:
> The only real user of the T10 OSD protocol, the pNFS object layout
> driver never went to the point of having shipping products, and we
> removed it 1.5 years ago. Exofs is just a simple example without
> real life users.
>
You have failed to say wha
On 31/10/18 23:10, Douglas Gilbert wrote:
> On 2018-10-31 4:57 p.m., Boaz Harrosh wrote:
>> On 30/10/18 09:45, Christoph Hellwig wrote:
>>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote:
>>>> LGTM, for both:
>>>
>>> I also have this on
-time checks added by
> Phillip Potter to make sure they remain the same as FT_x values
>
> v1:
> - Initial implementation
>
> Signed-off-by: Phillip Potter
Yes thank you, totally
ACK-by: Boaz Harrosh
> ---
> fs/exofs/dir.c | 49 ++--
^
>
> Just remove the attribute because it hasn't been correct since the
> initial addition of this file in commit b14f8ab28449 ("exofs: Kbuild,
> Headers and osd utils").
>
> Reported-by: Nick Desaulniers
> Reviewed-by: Nick Desaulnie
On 18/05/18 17:14, Christopher Lameter wrote:
> On Tue, 15 May 2018, Boaz Harrosh wrote:
>
>>> I don't think page tables work the way you think they work.
>>>
>>> + err = vm_insert_pfn_prot(zt->vma, zt_addr, pfn, prot);
>>>
>>
On 15/05/18 17:17, Peter Zijlstra wrote:
<>
>>
>> So I would love some mm guy to explain where are those bits collected?
>
> Depends on the architecture, some architectures only ever set bits,
> some, like x86, clear bits again. You want to look at switch_mm().
>
> Basically x86 clears the bit ag
On 15/05/18 17:18, Matthew Wilcox wrote:
> On Tue, May 15, 2018 at 05:10:57PM +0300, Boaz Harrosh wrote:
>> I'm not a lawyer either but I think I'm doing OK. Because I am doing exactly
>> like FUSE is doing. Only some 15 years later, with modern CPUs in mind. I do
&
On 15/05/18 16:50, Matthew Wilcox wrote:
> On Tue, May 15, 2018 at 04:29:22PM +0300, Boaz Harrosh wrote:
>> On 15/05/18 15:03, Matthew Wilcox wrote:
>>> You're getting dangerously close to admitting that the entire point
>>> of this exercise is so that you can l
On 15/05/18 15:03, Matthew Wilcox wrote:
> On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote:
>> That would be very hard. Because that program would:
>> - need to be root
>> - need to start and pretend it is zus Server with the all mount
>> thread thing, re
On 15/05/18 14:54, Boaz Harrosh wrote:
> On 15/05/18 03:44, Matthew Wilcox wrote:
>> On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote:
>>> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh wrote:
>>>> In this project we utilize a per-core server thread so
On 15/05/18 15:07, Mark Rutland wrote:
> On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote:
>> On 15/05/18 03:41, Matthew Wilcox wrote:
>>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote:
>>>> On 14/05/18 22:15, Matthew Wilcox wrote:
>&
On 15/05/18 15:09, Peter Zijlstra wrote:
> On Tue, May 15, 2018 at 02:41:41PM +0300, Boaz Harrosh wrote:
>> On 15/05/18 14:11, Matthew Wilcox wrote:
>
>>> You're still thinking about this from the wrong perspective. If you
>>> were writing a program to attack
On 15/05/18 14:47, Peter Zijlstra wrote:
> On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote:
>> Yes I know, but that is exactly the point of this flag. I know that this
>> address is only ever accessed from a single core. Because it is an mmap (vma)
>> of an O_T
On 15/05/18 03:44, Matthew Wilcox wrote:
> On Mon, May 14, 2018 at 02:49:01PM -0700, Andrew Morton wrote:
>> On Mon, 14 May 2018 20:28:01 +0300 Boaz Harrosh wrote:
>>> In this project we utilize a per-core server thread so everything
>>> is kept local. If we use the
On 15/05/18 14:11, Matthew Wilcox wrote:
> On Tue, May 15, 2018 at 01:43:23PM +0300, Boaz Harrosh wrote:
>> On 15/05/18 03:41, Matthew Wilcox wrote:
>>> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote:
>>>> On 14/05/18 22:15, Matthew Wilcox wrote:
>&
On 15/05/18 10:08, Christoph Hellwig wrote:
> On Mon, May 14, 2018 at 09:26:13PM +0300, Boaz Harrosh wrote:
>> I am please pushing for this patch ahead of the push of ZUFS, because
>> this is the only patch we need from otherwise an STD Kernel.
>>
>> We are partnering
On 15/05/18 03:41, Matthew Wilcox wrote:
> On Mon, May 14, 2018 at 10:37:38PM +0300, Boaz Harrosh wrote:
>> On 14/05/18 22:15, Matthew Wilcox wrote:
>>> On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote:
>>>> On a call to mmap an mmap provider (like an FS)
On 14/05/18 22:15, Matthew Wilcox wrote:
> On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote:
>> On a call to mmap an mmap provider (like an FS) can put
>> this flag on vma->vm_flags.
>>
>> The VM_LOCAL_CPU flag tells the Kernel that the vma will be used
&
On 14/05/18 20:28, Boaz Harrosh wrote:
>
> On a call to mmap an mmap provider (like an FS) can put
> this flag on vma->vm_flags.
>
> The VM_LOCAL_CPU flag tells the Kernel that the vma will be used
> from a single-core only, and therefore invalidation (flush_tlb) of
> P
and the threads are interfering with each other. This is because
flush-tlb is scheduled on all (other) CPUs.
NOTE: This vma (VM_LOCAL_CPU) is never used during a page_fault. It is
always used in a synchronous way from a thread pinned to a single core.
Signed-off-by: Boaz Harrosh
---
arch/x86/mm/tlb
o avoid 80 character column limit.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
ACK-BY: Boaz Harrosh
> Signed-off-by: Kees Cook
> ---
> drivers/scsi/osd/osd_initiator.c | 16
> 1 file changed
On 05/21/2017 06:40 PM, Fabian Frederick wrote:
> Filesystems generally use SUPER_MAGIC values from magic.h
> instead of a local definition.
>
Is fine by me to move to magic.h but ...
> Signed-off-by: Fabian Frederick
> ---
> fs/exofs/common.h | 6 +-
> include/uapi/linux/magic.h
; Signed-off-by: Christoph Hellwig
>> ---
>> MAINTAINERS | 4
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 1bb06c5f7716..28dd83a1d9e2 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9418,10
On 04/22/2017 03:48 PM, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in ORE_ERR message and make word all
> lower case.
>
> Signed-off-by: Colin Ian King
Thanks
ACK-by: Boaz Harrosh
> ---
> fs/exofs/ore.c | 2 +-
> 1 file changed,
On 04/21/2017 05:00 PM, Trond Myklebust wrote:
> Maintenance is not development. It’s about doing all the followup
> _after_ the feature is declared to be developed. That’s been missing
> for quite some time in the case of the OSD pNFS code, which is why
> I’m not even bothering to consider staging
On 04/20/2017 11:18 PM, Trond Myklebust wrote:
<>
>
> OK. I'm applying this patch for the 4.12 merge window.
That is understandable this code was not tested for a long while
> If, as Boaz
> suggests, there is still an interest in exofs, then I suggest we put
> that to the test by moving it into
On 04/07/2017 10:50 PM, Bart Van Assche wrote:
> On Fri, 2017-04-07 at 13:29 -0600, Logan Gunthorpe wrote:
>> On 07/04/17 09:49 AM, Bart Van Assche wrote:
>>> Sorry that I had not yet noticed Logan's patch series. Should my two
>>> patches that conflict with Logan's patch series be dropped and rewo
On 04/12/2017 07:01 PM, Christoph Hellwig wrote:
> This was just a proof of concept user for the SCSI OSD library, and
> never had any real users.
>
> Signed-off-by: Christoph Hellwig
Yes please remove this driver
ACK-by Boaz Harrosh
> ---
> drivers/block/Kconfig | 16 -
On 04/12/2017 07:01 PM, Christoph Hellwig wrote:
Hi Sir Christoph
> The only real user of the T10 OSD protocol, the pNFS object layout
> driver never went to the point of having shipping products, and the
> other two users (osdblk and exofs) were simple example of it's usage.
>
I understand why
On 03/30/2017 09:35 PM, Jeff Layton wrote:
<>
> Yeah, I imagine we'd need a on-disk change for this unless there's
> something already present that we could use in place of a crash counter.
>
Perhaps we can use s_mtime and/or s_wtime in some way, I'm not sure
what is a parallel for that in xfs.
On 03/30/2017 09:45 PM, Linus Torvalds wrote:
> On Thu, Mar 30, 2017 at 11:26 AM, Christoph Hellwig wrote:
>>
>> That would be nice, but still won't work as we blindly copy f_flags
>> into F_GETFL, not even masking our internal FMODE_ bits.
>
> Ok, *that* is just silly of us, and we could try to
On 03/23/2017 12:41 PM, Dan Carpenter wrote:
> We don't call the remove() function unless probe() succeeds so "oud"
> can't be NULL here. Plus, if it were NULL, we dereference it on the
> next line so it would crash anyway.
>
> Signed-off-by: Dan Carpenter
&
On 02/28/2017 03:11 AM, Jeff Layton wrote:
<>
>
> I'll probably have questions about the read side as well, but for now it
> looks like it's mostly used in an ad-hoc way to communicate errors
> across subsystems (block to fs layer, for instance).
If memory does not fail me it used to be checked l
On 12/27/2016 06:04 PM, Ming Lei wrote:
> Signed-off-by: Ming Lei
Cool
ACK-by: Boaz Harrosh
> ---
> fs/exofs/ore.c | 3 ++-
> fs/exofs/ore_raid.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/exofs/ore.c b/fs/exofs/ore.c
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/23/2016 07:24 PM, Boaz Harrosh wrote:
> On 08/23/2016 05:05 PM, Miklos Szeredi wrote:
>> This is trivial to do:
>>
>> - add flags argument to foo_rename()
>> - check if flags is zero
>> - assign foo_rename() to .rename2 instead of .rename
>>
>>
;
> 9p, afs, ceph, coda, ecryptfs, exofs, kernfs, lustre, ncpfs, nfs, ocfs2,
> orangefs.
>
> After this, we can get rid of the duplicate interfaces for rename.
>
> Signed-off-by: Miklos Szeredi
> Cc: Eric Van Hensbergen
> Cc: David Howells
> Cc: Ilya Dryomov
> Cc:
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
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
On 05/02/2016 09:48 PM, Dan Williams wrote:
<>
>> And then it keeps broken the aligned buffered writes, which are still
>> broken after this set.
>
> ...identical to the current situation with a traditional disk.
>
Not true!! please see what I wrote "aligned buffered writes"
If there are no read
via ->direct_access for the check.
>(Christoph Hellwig)
> - Call bdev_direct_access() with sector 0 for the check.
>(Boaz Harrosh)
>
> ---
> Toshi Kani (3):
> 1/3 ext4: Add alignment check for DAX mount
> 2/3 ext2: Add alignment check for DAX mount
> 3/3
On 05/02/2016 09:10 PM, Dan Williams wrote:
<>
>
> The semantic I am talking about preserving is:
>
> buffered / unaligned write of a bad sector => -EIO on reading into the
> page cache
>
What about aligned buffered write? like write 0-to-eof
This still broken? (and is what restore apps do)
>
On 05/02/2016 07:49 PM, Dan Williams wrote:
> On Mon, May 2, 2016 at 9:22 AM, Boaz Harrosh wrote:
>> On 05/02/2016 07:01 PM, Dan Williams wrote:
>>> On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
>>>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>>>&
On 05/02/2016 07:01 PM, Dan Williams wrote:
> On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>>> All IO in a dax filesystem used to go through dax_do_io, which cannot
>>> handle media errors, and thus cannot provi
On 05/02/2016 06:51 PM, Vishal Verma wrote:
> On Mon, 2016-05-02 at 18:41 +0300, Boaz Harrosh wrote:
>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>>>
>>> All IO in a dax filesystem used to go through dax_do_io, which
>>> cannot
>>> handle media er
On 04/29/2016 12:16 AM, Vishal Verma wrote:
> All IO in a dax filesystem used to go through dax_do_io, which cannot
> handle media errors, and thus cannot provide a recovery path that can
> send a write through the driver to clear errors.
>
> Add a new iocb flag for DAX, and set it only for DAX mo
On 05/01/2016 08:31 PM, Christoph Hellwig wrote:
> On Fri, Apr 29, 2016 at 02:39:33PM -0600, Toshi Kani wrote:
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 304c712..90a8670 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -3421,6 +3421,12 @@ static int ext4_fill_super(st
On 04/29/2016 11:39 PM, Toshi Kani wrote:
> When a partition is not aligned by 4KB, mount -o dax succeeds,
> but any read/write access to the filesystem fails, except for
> metadata update.
>
> Add alignment check to ext4_fill_super() when -o dax is specified.
>
> Reported-by: Micah Parrish
> Si
;
>
> - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
>
> - page_cache_get() -> get_page();
>
> - page_cache_release() -> put_page();
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Boaz Harrosh
ACK-by: Boaz Harrosh
Could you please push this t
f-by: NeilBrown
Tested-by: Boaz Harrosh
Yes I sent in the same exact patch several times. This is not the
only driver that has this "wasted code" BTW.
I hope it will be finally removed. Thanks Neil
Boaz
> ---
> drivers/nvdimm/pmem.c | 19 +--
> 1 file change
On 02/24/2016 01:21 PM, Sudip Mukherjee wrote:
> The variable is_ver1 is always true and so OSD_CAP_LEN can never be
> used.
> Reported by Coverity.
>
> Signed-off-by: Sudip Mukherjee
ACK-by: Boaz harrosh
Thanks
> ---
>
> v2: Joe Perches asked to mention the too
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
>>> init
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 cac
would be to change the casts to (u8*) aka
> (unsigned char*), but it is much simpler (and generates smaller code)
> to use the %ph extension which was created for such short hexdumps.
>
Ha real cool, thanks I hated that crap
ACK-by: Boaz Harrosh
> Signed-off-by: Rasmus Vi
hould be applied to v4.3 as well.
>>>
>>> [1] 0f90cc6609c7 mm, dax: fix DAX deadlocks
>>> [2] 52a2b53ffde6 mm, dax: use i_mmap_unlock_write() in do_cow_fault()
>>> [3] 843172978bb9 dax: fix race between simultaneous faults
>>> [4] 2e4cdab0584f mm: all
On 11/16/2015 11:28 AM, Takashi Iwai wrote:
<>
>>
>> Hi Greg
>>
>> Please include the mainline patch:
>> [2db1a57] ALSA: pci: depend on ZONE_DMA (by Dan Williams)
>>
>> To the stable tree for v4.3.X Kernel.
>>
>> This patch is needed for proper operation of the 4.3 pmem.ko driver. Long
>> stor
On 11/16/2015 09:40 AM, Takashi Iwai wrote:
> On Sun, 15 Nov 2015 11:53:11 +0100,
> Boaz Harrosh wrote:
>>
>> On 11/12/2015 10:38 PM, Takashi Iwai wrote:
>>> On Thu, 12 Nov 2015 21:13:57 +0100,
>>> Dan Williams wrote:
>>>>
>>>> Ther
On 11/12/2015 10:38 PM, Takashi Iwai wrote:
> On Thu, 12 Nov 2015 21:13:57 +0100,
> Dan Williams wrote:
>>
>> There are several sound drivers that 'select ZONE_DMA'. This is
>> backwards as ZONE_DMA is an architecture capability exported to drivers.
>> Switch the polarity of the dependency to disa
by: Dan Williams
Yes sorry about that. I had the exact patch in my original 4.3-rc1
tree but forgot to send it.
Reviewed-by: Boaz Harrosh
You will need stabe@ for 4.3 as well.
Thanks
Boaz
> ---
> sound/pci/Kconfig | 24
> 1 file changed, 12 insertions(+)
On 11/03/2015 04:49 AM, Hugh Dickins wrote:
> On Mon, 2 Nov 2015, Boaz Harrosh wrote:
>> On 11/02/2015 01:39 AM, Hugh Dickins wrote:
>> <>
>>>> This patch is not correct!
>>>
>>> I think you have actually confirmed that the patch is correct:
>
On 11/02/2015 01:39 AM, Hugh Dickins wrote:
<>
>> This patch is not correct!
>
> I think you have actually confirmed that the patch is correct:
> why bother to test PageDirty or PageWriteback when PageUptodate
> already tells you what you need?
>
> Or do these filesystems do something unusual wit
On 10/29/2015 08:43 PM, Hugh Dickins wrote:
> Patch "mm: migrate dirty page without clear_page_dirty_for_io etc",
> presently staged in mmotm and linux-next, simplifies the migration of
> a PageDirty pagecache page: one stat needs moving from zone to zone
> and that's about all.
>
> It's convenien
On 09/29/2015 06:46 PM, Yaowei Bai wrote:
> On Tue, Sep 29, 2015 at 04:47:30PM +0300, Boaz Harrosh wrote:
>> On 09/28/2015 04:43 PM, Yaowei Bai wrote:
>>> As new_valid_dev always returns 1, so !new_valid_dev check is not
>>> needed, remove it.
>>>
>>>
On 09/28/2015 04:43 PM, Yaowei Bai wrote:
> As new_valid_dev always returns 1, so !new_valid_dev check is not
> needed, remove it.
>
> Signed-off-by: Yaowei Bai
ACK-by: Boaz Harrosh
Please submit this through some General tree like the vfs or mm-tree
Thanks
Boaz
> ---
>
On 09/24/2015 05:52 AM, Dave Chinner wrote:
> On Wed, Sep 23, 2015 at 02:40:00PM -0600, Ross Zwisler wrote:
>> Fix the deadlock exposed by xfstests generic/075. Here is the sequence
>> that was causing us to deadlock:
>>
>> 1) enter __dax_fault()
>> 2) page = find_get_page() gives us a page, so sk
On 09/23/2015 12:04 PM, Dave Chinner wrote:
> On Tue, Sep 22, 2015 at 08:00:29PM -0700, Dan Williams wrote:
<>
>> The kaddr is coming from the devm_memremap() in the pmem driver that
>> gets unmapped after the device is released by the driver.
>
> Perhaps the better solution is to not tear down th
On 09/02/2015 07:19 PM, Dave Hansen wrote:
> On 09/02/2015 09:00 AM, Boaz Harrosh wrote:
>>>> We are going to have 2-socket systems with 6TB of persistent memory in
>>>> them. I think it's important to design this mechanism so that it scales
>>>> to me
On 09/02/2015 10:04 PM, Ross Zwisler wrote:
> On Tue, Sep 01, 2015 at 03:18:41PM +0300, Boaz Harrosh wrote:
<>
>> Apps expect all these to work:
>> 1. open mmap m-write msync ... close
>> 2. open mmap m-write fsync ... close
>> 3. open mmap m-write unmap ... fsync
On 09/02/2015 06:39 PM, Dave Hansen wrote:
> On 09/02/2015 08:18 AM, Boaz Harrosh wrote:
>> On 09/02/2015 05:23 PM, Dave Hansen wrote:
>>>> I'd be curious what the cost is in practice. Do you have any actual
>>>> numbers of the cost of doing it this way?
On 09/02/2015 05:23 PM, Dave Hansen wrote:
<>
> I'd be curious what the cost is in practice. Do you have any actual
> numbers of the cost of doing it this way?
>
> Even if the instruction is a "noop", I'd really expect the overhead to
> really add up for a tens-of-gigabytes mapping, no matter how
On 09/02/2015 12:47 PM, Kirill A. Shutemov wrote:
<>
>
> I don't insist on applying the patch. And I worry about false-positives.
>
Thanks, yes
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On 09/02/2015 08:17 AM, Dave Chinner wrote:
> On Tue, Sep 01, 2015 at 09:19:45PM -0600, Ross Zwisler wrote:
>> On Wed, Sep 02, 2015 at 08:21:20AM +1000, Dave Chinner wrote:
>>> Which means applications that should "just work" without
>>> modification on DAX are now subtly broken and don't actually
On 09/02/2015 06:19 AM, Ross Zwisler wrote:
> On Wed, Sep 02, 2015 at 08:21:20AM +1000, Dave Chinner wrote:
>> Which means applications that should "just work" without
>> modification on DAX are now subtly broken and don't actually
>> guarantee data is safe after a crash. That's a pretty nasty
>> l
On 09/02/2015 12:37 PM, Boaz Harrosh wrote:
>>
>> + /*
>> +* Make sure that for VM_MIXEDMAP VMA has both
>> +* vm_ops->page_mkwrite and vm_ops->pfn_mkwrite or has none.
>> +*/
>> +
On 09/02/2015 12:13 PM, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2015 at 08:49:22AM +1000, Dave Chinner wrote:
>> On Tue, Sep 01, 2015 at 01:08:04PM +0300, Kirill A. Shutemov wrote:
>>> On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
On Mon, Aug 31, 2015 at 12:59:44PM -0600, R
On 08/31/2015 09:59 PM, Ross Zwisler wrote:
> For DAX msync we just need to flush the given range using
> wb_cache_pmem(), which is now a public part of the PMEM API.
>
> The inclusion of in fs/dax.c was done to make checkpatch
> happy. Previously it was complaining about a bunch of undeclared
>
On 09/01/2015 10:06 AM, Christoph Hellwig wrote:
> On Tue, Sep 01, 2015 at 09:38:03AM +1000, Dave Chinner wrote:
>> On Mon, Aug 31, 2015 at 12:59:44PM -0600, Ross Zwisler wrote:
>>> For DAX msync we just need to flush the given range using
>>> wb_cache_pmem(), which is now a public part of the PMEM
On 09/01/2015 01:08 PM, Kirill A. Shutemov wrote:
<>
>
> Is that because XFS doesn't provide vm_ops->pfn_mkwrite?
>
Right that would explain it, because I sent that patch exactly to solve
this problem. I haven't looked at latest code for a while but I should
checkout the latest and make a patch
On 09/01/2015 02:10 PM, Kirill A. Shutemov wrote:
> On Tue, Sep 01, 2015 at 01:54:26PM +0300, Boaz Harrosh wrote:
>> On 09/01/2015 01:22 PM, Kirill A. Shutemov wrote:
>>> For VM_PFNMAP and VM_MIXEDMAP we use vm_ops->pfn_mkwrite instead of
>>> vm_ops->page_mkwrite t
[In our system every modified pmem block is also RDMAed to a remote
pmem for HA, a missed modification will make the two copies unsynced]
Thanks for catching this
Boaz
> Signed-off-by: Kirill A. Shutemov
> Cc: Yigal Korman
> Cc: Boaz Harrosh
> Cc: Matthew Wilcox
> Cc: Jan K
1 - 100 of 573 matches
Mail list logo
