FW: Proof Of Payment
We have paid. Please see the attached proof of payments for your Invoice. Should you need anything else, please let us know. Best regards Shermaye Alcide Financial/Credit Controller Direct Tel: +27 (0) 161 777 222 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
linux-nvdimm：如何科学管理固定资产3580
附 件 亲 启 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v4 1/3] dax: Add an enum for specifying dax wakup mode
On Fri, Apr 23, 2021 at 09:07:21AM -0400, Vivek Goyal wrote:
> +enum dax_wake_mode {
> + WAKE_NEXT,
> + WAKE_ALL,
> +};
Why define them in this order when ...
> @@ -196,7 +207,7 @@ static void dax_wake_entry(struct xa_state *xas, void
> *entry, bool wake_all)
>* must be in the waitqueue and the following check will see them.
>*/
> if (waitqueue_active(wq))
> - __wake_up(wq, TASK_NORMAL, wake_all ? 0 : 1, );
> + __wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1, );
... they're used like this? This is almost as bad as
enum bool {
true,
false,
};
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v4 1/3] dax: Add an enum for specifying dax wakup mode
On Mon, Apr 26, 2021 at 01:52:17PM -0400, Vivek Goyal wrote:
> On Mon, Apr 26, 2021 at 02:46:32PM +0100, Matthew Wilcox wrote:
> > On Fri, Apr 23, 2021 at 09:07:21AM -0400, Vivek Goyal wrote:
> > > +enum dax_wake_mode {
> > > + WAKE_NEXT,
> > > + WAKE_ALL,
> > > +};
> >
> > Why define them in this order when ...
> >
> > > @@ -196,7 +207,7 @@ static void dax_wake_entry(struct xa_state *xas, void
> > > *entry, bool wake_all)
> > >* must be in the waitqueue and the following check will see them.
> > >*/
> > > if (waitqueue_active(wq))
> > > - __wake_up(wq, TASK_NORMAL, wake_all ? 0 : 1, );
> > > + __wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1, );
> >
> > ... they're used like this? This is almost as bad as
> >
> > enum bool {
> > true,
> > false,
> > };
>
> Hi Matthew,
>
> So you prefer that I should switch order of WAKE_NEXT and WAKE_ALL?
>
> enum dax_wake_mode {
> WAKE_ALL,
> WAKE_NEXT,
> };
That, yes.
> And then do following to wake task.
>
> if (waitqueue_active(wq))
> __wake_up(wq, TASK_NORMAL, mode, );
No, the third argument to __wake_up() is a count, not an enum. It just so
happens that '0' means 'all' and we only ever wake up 1 and not, say, 5.
So the logical way to define the enum is ALL, NEXT which _just happens
to match_ the usage of __wake_up().
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v4 1/3] dax: Add an enum for specifying dax wakup mode
On Mon, Apr 26, 2021 at 02:46:32PM +0100, Matthew Wilcox wrote:
> On Fri, Apr 23, 2021 at 09:07:21AM -0400, Vivek Goyal wrote:
> > +enum dax_wake_mode {
> > + WAKE_NEXT,
> > + WAKE_ALL,
> > +};
>
> Why define them in this order when ...
>
> > @@ -196,7 +207,7 @@ static void dax_wake_entry(struct xa_state *xas, void
> > *entry, bool wake_all)
> > * must be in the waitqueue and the following check will see them.
> > */
> > if (waitqueue_active(wq))
> > - __wake_up(wq, TASK_NORMAL, wake_all ? 0 : 1, );
> > + __wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1, );
>
> ... they're used like this? This is almost as bad as
>
> enum bool {
> true,
> false,
> };
Hi Matthew,
So you prefer that I should switch order of WAKE_NEXT and WAKE_ALL?
enum dax_wake_mode {
WAKE_ALL,
WAKE_NEXT,
};
And then do following to wake task.
if (waitqueue_active(wq))
__wake_up(wq, TASK_NORMAL, mode, );
I am fine with this if you like this better.
Or you are suggesting that don't introduce "enum dax_wake_mode" to
begin with.
Vivek
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v4 1/3] dax: Add an enum for specifying dax wakup mode
On Mon, Apr 26, 2021 at 07:02:11PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 26, 2021 at 01:52:17PM -0400, Vivek Goyal wrote:
> > On Mon, Apr 26, 2021 at 02:46:32PM +0100, Matthew Wilcox wrote:
> > > On Fri, Apr 23, 2021 at 09:07:21AM -0400, Vivek Goyal wrote:
> > > > +enum dax_wake_mode {
> > > > + WAKE_NEXT,
> > > > + WAKE_ALL,
> > > > +};
> > >
> > > Why define them in this order when ...
> > >
> > > > @@ -196,7 +207,7 @@ static void dax_wake_entry(struct xa_state *xas,
> > > > void *entry, bool wake_all)
> > > > * must be in the waitqueue and the following check will see
> > > > them.
> > > > */
> > > > if (waitqueue_active(wq))
> > > > - __wake_up(wq, TASK_NORMAL, wake_all ? 0 : 1, );
> > > > + __wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1,
> > > > );
> > >
> > > ... they're used like this? This is almost as bad as
> > >
> > > enum bool {
> > > true,
> > > false,
> > > };
> >
> > Hi Matthew,
> >
> > So you prefer that I should switch order of WAKE_NEXT and WAKE_ALL?
> >
> > enum dax_wake_mode {
> > WAKE_ALL,
> > WAKE_NEXT,
> > };
>
> That, yes.
>
> > And then do following to wake task.
> >
> > if (waitqueue_active(wq))
> > __wake_up(wq, TASK_NORMAL, mode, );
>
> No, the third argument to __wake_up() is a count, not an enum. It just so
> happens that '0' means 'all' and we only ever wake up 1 and not, say, 5.
> So the logical way to define the enum is ALL, NEXT which _just happens
> to match_ the usage of __wake_up().
Ok, In that case, I will retain existing code.
__wake_up(wq, TASK_NORMAL, mode == WAKE_ALL ? 0 : 1, );
Vivek
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v2 1/3] fsdax: Factor helpers to simplify dax fault code
On Wed, Apr 07, 2021 at 09:38:21PM +0800, Shiyang Ruan wrote:
> The dax page fault code is too long and a bit difficult to read. And it
> is hard to understand when we trying to add new features. Some of the
> PTE/PMD codes have similar logic. So, factor them as helper functions to
> simplify the code.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Ritesh Harjani
> ---
> fs/dax.c | 153 ++-
> 1 file changed, 84 insertions(+), 69 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index b3d27fdc6775..f843fb8fbbf1 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
[snip]
> @@ -1355,19 +1379,8 @@ static vm_fault_t dax_iomap_pte_fault(struct vm_fault
> *vmf, pfn_t *pfnp,
> entry = dax_insert_entry(, mapping, vmf, entry, pfn,
>0, write && !sync);
>
> - /*
> - * If we are doing synchronous page fault and inode needs fsync,
> - * we can insert PTE into page tables only after that happens.
> - * Skip insertion for now and return the pfn so that caller can
> - * insert it after fsync is done.
> - */
> if (sync) {
> - if (WARN_ON_ONCE(!pfnp)) {
> - error = -EIO;
> - goto error_finish_iomap;
> - }
> - *pfnp = pfn;
> - ret = VM_FAULT_NEEDDSYNC | major;
> + ret = dax_fault_synchronous_pfnp(pfnp, pfn);
Is there a reason VM_FAULT_MAJOR should be left out here?
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
邮件群发软件---500元/月，赠送200万邮箱数据
每台电脑日发5-20万邮箱数据无需发件箱的邮件群发软件外贸、物流、展会业务好帮手 E-mail : sales0769@hotmail.comQQ咨询：3351665625 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
RE: [PATCH v3 1/3] fsdax: Factor helpers to simplify dax fault code
> -Original Message-
> From: Ira Weiny
> Sent: Tuesday, April 27, 2021 7:38 AM
> Subject: Re: [PATCH v3 1/3] fsdax: Factor helpers to simplify dax fault code
>
> On Thu, Apr 22, 2021 at 09:44:59PM +0800, Shiyang Ruan wrote:
> > The dax page fault code is too long and a bit difficult to read. And
> > it is hard to understand when we trying to add new features. Some of
> > the PTE/PMD codes have similar logic. So, factor them as helper
> > functions to simplify the code.
> >
> > Signed-off-by: Shiyang Ruan
> > Reviewed-by: Christoph Hellwig
> > Reviewed-by: Ritesh Harjani
> > ---
> > fs/dax.c | 153
> > ++-
> > 1 file changed, 84 insertions(+), 69 deletions(-)
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index b3d27fdc6775..f843fb8fbbf1 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
>
> [snip]
>
> > @@ -1355,19 +1379,8 @@ static vm_fault_t dax_iomap_pte_fault(struct
> vm_fault *vmf, pfn_t *pfnp,
> > entry = dax_insert_entry(, mapping, vmf, entry, pfn,
> > 0, write && !sync);
> >
> > - /*
> > -* If we are doing synchronous page fault and inode needs fsync,
> > -* we can insert PTE into page tables only after that happens.
> > -* Skip insertion for now and return the pfn so that caller can
> > -* insert it after fsync is done.
> > -*/
> > if (sync) {
> > - if (WARN_ON_ONCE(!pfnp)) {
> > - error = -EIO;
> > - goto error_finish_iomap;
> > - }
> > - *pfnp = pfn;
> > - ret = VM_FAULT_NEEDDSYNC | major;
> > + ret = dax_fault_synchronous_pfnp(pfnp, pfn);
>
> I commented on the previous version... So I'll ask here too.
>
> Why is it ok to drop 'major' here?
This dax_iomap_pte_fault () finally returns 'ret | major', so I think the major
here is not dropped. The origin code seems OR the return value and major twice.
--
Thanks,
Ruan Shiyang.
>
> Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v3 1/3] fsdax: Factor helpers to simplify dax fault code
On Thu, Apr 22, 2021 at 09:44:59PM +0800, Shiyang Ruan wrote:
> The dax page fault code is too long and a bit difficult to read. And it
> is hard to understand when we trying to add new features. Some of the
> PTE/PMD codes have similar logic. So, factor them as helper functions to
> simplify the code.
>
> Signed-off-by: Shiyang Ruan
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Ritesh Harjani
> ---
> fs/dax.c | 153 ++-
> 1 file changed, 84 insertions(+), 69 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index b3d27fdc6775..f843fb8fbbf1 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
[snip]
> @@ -1355,19 +1379,8 @@ static vm_fault_t dax_iomap_pte_fault(struct vm_fault
> *vmf, pfn_t *pfnp,
> entry = dax_insert_entry(, mapping, vmf, entry, pfn,
>0, write && !sync);
>
> - /*
> - * If we are doing synchronous page fault and inode needs fsync,
> - * we can insert PTE into page tables only after that happens.
> - * Skip insertion for now and return the pfn so that caller can
> - * insert it after fsync is done.
> - */
> if (sync) {
> - if (WARN_ON_ONCE(!pfnp)) {
> - error = -EIO;
> - goto error_finish_iomap;
> - }
> - *pfnp = pfn;
> - ret = VM_FAULT_NEEDDSYNC | major;
> + ret = dax_fault_synchronous_pfnp(pfnp, pfn);
I commented on the previous version... So I'll ask here too.
Why is it ok to drop 'major' here?
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
