From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org,
kexec@lists.infradead.org, linux-bcache@vger.kernel.org,
linux-mtd@lists.infradead.org, devel@driverdev.osuosl.org,
linux-efi@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-aio@kvack.org,
io-uring@vger.kernel.org, linux-erofs@l ists.ozlabs.org,
linux-um@lists.infradead.org,
linux-ntfs-dev@lists.sourceforge.net,
reiserfs-devel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org, cluster-devel@redhat.com,
ecryptfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-afs@lists.infradead.org,
linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
drbd-dev@lists.linbit.com, linux-block@vger.kernel.org,
xen-devel@lists.xenproject.org, linux-cachefs@redhat.com,
samba-technical@lists.samba.org,
intel-wired-lan@lists.osuosl.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org,
kexec@lists.infradead.org, linux-bcache@vger.kernel.org,
linux-mtd@lists.infradead.org, devel@driverdev.osuosl.org,
linux-efi@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-aio@kvack.org,
io-uring@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-um@lists.infradead.org,
linux-ntfs-dev@lists.sourceforge.net,
reiserfs-devel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org, cluster-devel@redhat.com,
ecryptfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-afs@lists.infradead.org,
linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
drbd-dev@lists.linbit.com, linux-block@vger.kernel.org,
xen-devel@lists.xenproject.org, linux-cachefs@redhat.com,
samba-technical@lists.samba.org,
intel-wired-lan@lists.osuosl.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Mon, 12 Oct 2020 05:28:18 +0000 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny at intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Coly Li <colyli@suse.de>
Cc: linux-aio@kvack.org, linux-efi@vger.kernel.org,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
linux-mmc@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
target-devel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kselftest@vger.kernel.org, samba-technical@lists.samba.org,
Thomas Gleixner <tglx@linutronix.de>,
drbd-dev@lists.linbit.com, devel@driverdev.osuosl.org,
linux-cifs@vger.kernel.org, linux-nilfs@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-rdma@vger.kernel.org, x86@kernel.org,
ceph-devel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
io-uring@vger.kernel.org, cluster-devel@redhat.com,
Ingo Molnar <mingo@redhat.com>,
intel-wired-lan@lists.osuosl.org, xen-devel@lists.xenproject.org,
linux-ext4@vger.kernel.org,
Kent Overstreet <kent.overstreet@gmail.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-afs@lists.infradead.org, linux-um@lists.infradead.org,
intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-cachefs@redhat.com, linux-nfs@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net, netdev@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
Date: Sun, 11 Oct 2020 22:28:18 -0700 [thread overview]
Message-ID: <20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <c802fbf4-f67a-b205-536d-9c71b440f9c8@suse.de>
On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
> On 2020/10/10 03:50, ira.weiny at intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > These kmap() calls are localized to a single thread. To avoid the over
> > head of global PKRS updates use the new kmap_thread() call.
> >
>
> Hi Ira,
>
> There were a number of options considered.
>
> 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> 2) Introduce a flags parameter to kmap() to indicate if the mapping
> should be global or not
> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they
> require a global mapping of the pages
> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the
> mapping is to be used within that thread of execution only
>
>
> I copied the above information from patch 00/58 to this message. The
> idea behind kmap_thread() is fine to me, but as you said the new api is
> very easy to be missed in new code (even for me). I would like to be
> supportive to option 2) introduce a flag to kmap(), then we won't forget
> the new thread-localized kmap method, and people won't ask why a
> _thread() function is called but no kthread created.
Thanks for the feedback.
I'm going to hold off making any changes until others weigh in. FWIW, I kind
of like option 2 as well. But there is already kmap_atomic() so it seemed like
kmap_XXXX() was more in line with the current API.
Thanks,
Ira
>
> Thanks.
>
>
> Coly Li
>
next prev parent reply other threads:[~2020-10-12 5:28 UTC|newest]
Thread overview: 1245+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 19:49 [PATCH RFC PKS/PMEM 00/58] PMEM: Introduce stray write protection for PMEM ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 01/58] x86/pks: Add a global pkrs option ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 02/58] x86/pks/test: Add testing for global option ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 03/58] memremap: Add zone device access protection ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 04/58] kmap: Add stray access protection for device pages ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 06/58] kmap: Introduce k[un]map_thread debugging ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 07/58] drivers/drbd: Utilize new kmap_thread() ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 08/58] drivers/firmware_loader: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 09/58] drivers/gpu: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` [Cluster-devel] " Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` [Intel-wired-lan] " Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` [Intel-gfx] " Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` [f2fs-dev] " Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
2020-10-09 22:03 ` Daniel Vetter
[not found] ` <20201009220349.GQ438822-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` [Cluster-devel] " Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` [Intel-wired-lan] " Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` [Intel-gfx] " Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` [f2fs-dev] " Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-10 23:01 ` Ira Weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 10/58] drivers/rdma: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 11/58] drivers/net: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 12/58] fs/afs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 13/58] fs/btrfs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 14/58] fs/cifs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 15/58] fs/ecryptfs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 16/58] fs/gfs2: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 17/58] fs/nilfs2: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 18/58] fs/hfs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 19/58] fs/hfsplus: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 20/58] fs/jffs2: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 21/58] fs/nfs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 22/58] fs/f2fs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` [Cluster-devel] " Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` [Intel-wired-lan] " Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` [Intel-gfx] " Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` [f2fs-dev] " Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-09 21:34 ` Eric Biggers
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` [Cluster-devel] " Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` [Intel-wired-lan] " Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` [Intel-gfx] " Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` [f2fs-dev] " Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 0:39 ` Matthew Wilcox
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` [Cluster-devel] " Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` [Intel-wired-lan] " Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` [Intel-gfx] " Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` [f2fs-dev] " Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-10 1:30 ` Eric Biggers
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` [Cluster-devel] " Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` [Intel-wired-lan] " Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` [Intel-gfx] " Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` [f2fs-dev] " Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 6:56 ` Ira Weiny
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` [Intel-wired-lan] " Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` [Intel-gfx] " Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` [f2fs-dev] " Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-12 16:19 ` Eric Biggers
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` [Cluster-devel] " James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` [Intel-wired-lan] " James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` [Intel-gfx] " James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` [f2fs-dev] " James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-10 2:43 ` James Bottomley
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 23/58] fs/fuse: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: " ira.weiny
2020-10-09 19:49 ` [Cluster-devel] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [Intel-gfx] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` [f2fs-dev] " ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:49 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 25/58] fs/reiserfs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 26/58] fs/zonefs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` [Cluster-devel] " Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` [Intel-wired-lan] " Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` [Intel-gfx] " Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` [f2fs-dev] " Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-12 2:30 ` Damien Le Moal
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 27/58] fs/ubifs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 28/58] fs/cachefiles: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 29/58] fs/ntfs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 30/58] fs/romfs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 31/58] fs/vboxsf: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 32/58] fs/hostfs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 33/58] fs/cramfs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 34/58] fs/erofs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 35/58] fs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 36/58] fs/ext2: Use ext2_put_page ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 37/58] fs/ext2: Utilize new kmap_thread() ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 38/58] fs/isofs: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 39/58] fs/jffs2: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 40/58] net: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 41/58] drivers/target: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 42/58] drivers/scsi: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 43/58] drivers/mmc: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 44/58] drivers/xen: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 45/58] drivers/firmware: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 46/58] drives/staging: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 47/58] drivers/mtd: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 48/58] drivers/md: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` [Cluster-devel] " Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` [Intel-wired-lan] " Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` [Intel-gfx] " Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` [f2fs-dev] " Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-10 2:20 ` Coly Li
2020-10-12 5:28 ` Ira Weiny [this message]
2020-10-12 5:28 ` [Cluster-devel] " Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` [Intel-wired-lan] " Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` [Intel-gfx] " Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` [f2fs-dev] " Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 5:28 ` Ira Weiny
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` [Cluster-devel] " Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` [Intel-wired-lan] " Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` [Intel-gfx] " Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` [f2fs-dev] " Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-12 7:40 ` Coly Li
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 49/58] drivers/misc: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 50/58] drivers/android: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 51/58] kernel: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` [Cluster-devel] " Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` [Intel-wired-lan] " Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` [Intel-gfx] " Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` [f2fs-dev] " Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-10 3:43 ` Eric W. Biederman
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 52/58] mm: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 53/58] lib: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 54/58] powerpc: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 55/58] samples: " ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 56/58] dax: Stray access protection for dax_direct_access() ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 57/58] nvdimm/pmem: Stray access protection for pmem->virt_addr ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` [Cluster-devel] " John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` [Intel-wired-lan] " John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` [Intel-gfx] " John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` [f2fs-dev] " John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-10 2:53 ` John Hubbard
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` [Cluster-devel] " Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` [Intel-wired-lan] " Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` [Intel-gfx] " Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` [f2fs-dev] " Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-12 5:52 ` Ira Weiny
2020-10-09 19:50 ` [PATCH RFC PKS/PMEM 58/58] [dax|pmem]: Enable stray access protection ira.weiny
2020-10-09 19:50 ` [Cluster-devel] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-wired-lan] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [Intel-gfx] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` [f2fs-dev] " ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 19:50 ` ira.weiny
2020-10-09 22:51 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for PMEM: Introduce stray write protection for PMEM Patchwork
2020-10-10 11:36 ` [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread() Bernard Metzler
2020-10-10 11:36 ` [Cluster-devel] " Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` [Intel-wired-lan] " Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` [Intel-gfx] " Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` [f2fs-dev] " Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-10 11:36 ` Bernard Metzler
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` [Cluster-devel] " Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` [Intel-wired-lan] " Ira Weiny
2020-10-12 4:47 ` [Intel-gfx] " Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` [f2fs-dev] " Ira Weiny
2020-10-12 4:47 ` Ira Weiny
2020-10-12 4:47 ` Ira Weiny
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=20201012052817.GZ2046448@iweiny-DESK2.sc.intel.com \
--to=ira.weiny@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=colyli@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=fenghua.yu@intel.com \
--cc=io-uring@vger.kernel.org \
--cc=kent.overstreet@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-aio@kvack.org \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-erofs@l \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=target-devel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.