Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1548041 > unrolled thread

mm: fix typo of cache_alloc_zspage()

Back to article view | Back to linux.kernel

Contents

  mm: fix typo of cache_alloc_zspage() Xishi Qiu <qiuxishi@huawei.com> - 2016-12-29 03:10 +0100
    Re: mm: fix typo of cache_alloc_zspage() Minchan Kim <minchan@kernel.org> - 2016-12-29 07:50 +0100
      Re: mm: fix typo of cache_alloc_zspage() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-29 08:00 +0100
        Re: mm: fix typo of cache_alloc_zspage() Minchan Kim <minchan@kernel.org> - 2016-12-29 08:00 +0100
          Re: mm: fix typo of cache_alloc_zspage() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-29 08:40 +0100
            Re: mm: fix typo of cache_alloc_zspage() Minchan Kim <minchan@kernel.org> - 2016-12-29 09:00 +0100
              Re: mm: fix typo of cache_alloc_zspage() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-29 09:10 +0100
              Re: mm: fix typo of cache_alloc_zspage() Xishi Qiu <qiuxishi@huawei.com> - 2016-12-29 11:40 +0100
                Re: mm: fix typo of cache_alloc_zspage() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-12-30 02:10 +0100
    [PATCH V2] mm: fix typo of cache_alloc_zspage() Xishi Qiu <qiuxishi@huawei.com> - 2016-12-29 09:00 +0100

#1548041 — mm: fix typo of cache_alloc_zspage()

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
 mm/zsmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9cc3c0b..2d6c92e 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -364,7 +364,7 @@ static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
 {
 	return kmem_cache_alloc(pool->zspage_cachep,
 			flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
-};
+}
 
 static void cache_free_zspage(struct zs_pool *pool, struct zspage *zspage)
 {
-- 
1.8.3.1

[toc] | [next] | [standalone]

#1548202

On Thu, Dec 29, 2016 at 10:06:47AM +0800, Xishi Qiu wrote:
> Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
> ---
>  mm/zsmalloc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 9cc3c0b..2d6c92e 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -364,7 +364,7 @@ static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
>  {
>  	return kmem_cache_alloc(pool->zspage_cachep,
>  			flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
> -};
> +}

Although it's trivial, we need descritpion.
Please, could you resend to Andrew Morton with filling description?

Andrew Morton <akpm@linux-foundation.org>

Thanks.

[toc] | [prev] | [next] | [standalone]

#1548205

On (12/29/16 15:44), Minchan Kim wrote:
> On Thu, Dec 29, 2016 at 10:06:47AM +0800, Xishi Qiu wrote:
> > Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
> > ---
> >  mm/zsmalloc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 9cc3c0b..2d6c92e 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -364,7 +364,7 @@ static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
> >  {
> >  	return kmem_cache_alloc(pool->zspage_cachep,
> >  			flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
> > -};
> > +}
> 
> Although it's trivial, we need descritpion.
> Please, could you resend to Andrew Morton with filling description?

I don't know... do we want to have it as a separate patch?
may be we can fold it into some other patch someday later.

	-ss

[toc] | [prev] | [next] | [standalone]

#1548206

Hi Sergey,

On Thu, Dec 29, 2016 at 03:52:05PM +0900, Sergey Senozhatsky wrote:
> On (12/29/16 15:44), Minchan Kim wrote:
> > On Thu, Dec 29, 2016 at 10:06:47AM +0800, Xishi Qiu wrote:
> > > Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
> > > ---
> > >  mm/zsmalloc.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > > index 9cc3c0b..2d6c92e 100644
> > > --- a/mm/zsmalloc.c
> > > +++ b/mm/zsmalloc.c
> > > @@ -364,7 +364,7 @@ static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
> > >  {
> > >  	return kmem_cache_alloc(pool->zspage_cachep,
> > >  			flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
> > > -};
> > > +}
> > 
> > Although it's trivial, we need descritpion.
> > Please, could you resend to Andrew Morton with filling description?
> 
> I don't know... do we want to have it as a separate patch?
> may be we can fold it into some other patch someday later.

Xishi spent his time to make the patch(review,create/send). And I want to
give a credit to him. :)

Thanks.

[toc] | [prev] | [next] | [standalone]

#1548213

Hello,

On (12/29/16 15:59), Minchan Kim wrote:
[..]
> > I don't know... do we want to have it as a separate patch?
> > may be we can fold it into some other patch someday later.
> 
> Xishi spent his time to make the patch(review,create/send). And I want to
> give a credit to him. :)

sure, I didn't mean "let's seize the credit" :)  my reasoning was
that that patch hardly can be counted even as trivial. per
documentation:

: Trivial patches must qualify for one of the following rules:
:
: - Spelling fixes in documentation
: - Spelling fixes for errors which could break :manpage:`grep(1)`
: - Warning fixes (cluttering with useless warnings is bad)
: - Compilation fixes (only if they are actually correct)
: - Runtime fixes (only if they actually fix things)
: - Removing use of deprecated functions/macros
: - Contact detail and documentation fixes
: - Non-portable code replaced by portable code (even in arch-specific,
:   since people copy, as long as it's trivial)
: - Any fix by the author/maintainer of the file (ie. patch monkey
:   in re-transmission mode)


hence was my question. we can have it as "p.s. in this patch we also
remove XYZ reported by Xishi Qiu".

but up to you.



for instance, we can have Xishi's fix up as part of this "fix documentation
typos" patch. which can be counted in as trivial.


---

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9cc3c0b2c2c1..af7cd90c26f7 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -25,7 +25,7 @@
  * Usage of struct page flags:
  *     PG_private: identifies the first component page
  *     PG_private2: identifies the last component page
- *     PG_owner_priv_1: indentifies the huge component page
+ *     PG_owner_priv_1: identifies the huge component page
  *
  */
 
@@ -65,7 +65,7 @@
 #define ZS_ALIGN               8
 
 /*
- * A single 'zspage' is composed of up to 2^N discontiguous 0-order (single)
+ * A single 'zspage' is composed of up to 2^N discontinuous 0-order (single)
  * pages. ZS_MAX_ZSPAGE_ORDER defines upper limit on N.
  */
 #define ZS_MAX_ZSPAGE_ORDER 2
@@ -2383,7 +2383,7 @@ struct zs_pool *zs_create_pool(const char *name)
                goto err;
 
        /*
-        * Iterate reversly, because, size of size_class that we want to use
+        * Iterate reversely, because, size of size_class that we want to use
         * for merging should be larger or equal to current size.
         */
        for (i = zs_size_classes - 1; i >= 0; i--) {


---

	-ss

[toc] | [prev] | [next] | [standalone]

#1548225

On Thu, Dec 29, 2016 at 04:34:03PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (12/29/16 15:59), Minchan Kim wrote:
> [..]
> > > I don't know... do we want to have it as a separate patch?
> > > may be we can fold it into some other patch someday later.
> > 
> > Xishi spent his time to make the patch(review,create/send). And I want to
> > give a credit to him. :)
> 
> sure, I didn't mean "let's seize the credit" :)  my reasoning was
> that that patch hardly can be counted even as trivial. per
> documentation:
> 
> : Trivial patches must qualify for one of the following rules:
> :
> : - Spelling fixes in documentation
> : - Spelling fixes for errors which could break :manpage:`grep(1)`
> : - Warning fixes (cluttering with useless warnings is bad)
> : - Compilation fixes (only if they are actually correct)
> : - Runtime fixes (only if they actually fix things)
> : - Removing use of deprecated functions/macros
> : - Contact detail and documentation fixes
> : - Non-portable code replaced by portable code (even in arch-specific,
> :   since people copy, as long as it's trivial)
> : - Any fix by the author/maintainer of the file (ie. patch monkey
> :   in re-transmission mode)
> 
> 
> hence was my question. we can have it as "p.s. in this patch we also
> remove XYZ reported by Xishi Qiu".
> 
> but up to you.
> 
> 
> 
> for instance, we can have Xishi's fix up as part of this "fix documentation
> typos" patch. which can be counted in as trivial.

Xishi, Could you send your patch with fixing ones Sergey pointed out
if Sergey doesn't mind?

You should include Sergey's SOB, too.

> 
> 
> ---
> 
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 9cc3c0b2c2c1..af7cd90c26f7 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -25,7 +25,7 @@
>   * Usage of struct page flags:
>   *     PG_private: identifies the first component page
>   *     PG_private2: identifies the last component page
> - *     PG_owner_priv_1: indentifies the huge component page
> + *     PG_owner_priv_1: identifies the huge component page
>   *
>   */
>  
> @@ -65,7 +65,7 @@
>  #define ZS_ALIGN               8
>  
>  /*
> - * A single 'zspage' is composed of up to 2^N discontiguous 0-order (single)
> + * A single 'zspage' is composed of up to 2^N discontinuous 0-order (single)

Hmm, discontinuous is right?
I'm not a native but discontiguos is wrong? "contiguous" was used mm part widely.


>   * pages. ZS_MAX_ZSPAGE_ORDER defines upper limit on N.
>   */
>  #define ZS_MAX_ZSPAGE_ORDER 2
> @@ -2383,7 +2383,7 @@ struct zs_pool *zs_create_pool(const char *name)
>                 goto err;
>  
>         /*
> -        * Iterate reversly, because, size of size_class that we want to use
> +        * Iterate reversely, because, size of size_class that we want to use
>          * for merging should be larger or equal to current size.
>          */
>         for (i = zs_size_classes - 1; i >= 0; i--) {
> 
> 
> ---
> 
> 	-ss
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[toc] | [prev] | [next] | [standalone]

#1548231

On (12/29/16 16:56), Minchan Kim wrote:
> > for instance, we can have Xishi's fix up as part of this "fix documentation
> > typos" patch. which can be counted in as trivial.
> 
> Xishi, Could you send your patch with fixing ones Sergey pointed out
> if Sergey doesn't mind?

I don't.
  Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

will be more than enough (well, to me).


> > - * A single 'zspage' is composed of up to 2^N discontiguous 0-order (single)
> > + * A single 'zspage' is composed of up to 2^N discontinuous 0-order (single)
> 
> Hmm, discontinuous is right?
> I'm not a native but discontiguos is wrong? "contiguous" was used mm part widely.

oh, you're definitely much closer to native speaker than `aspell' tool!
you're right. Xishi, please drop that 'discontiguous' "correction".
sorry for that.

	-ss

[toc] | [prev] | [next] | [standalone]

#1548284

On 2016/12/29 15:56, Minchan Kim wrote:

> On Thu, Dec 29, 2016 at 04:34:03PM +0900, Sergey Senozhatsky wrote:
>> Hello,
>>
>> On (12/29/16 15:59), Minchan Kim wrote:
>> [..]
>>>> I don't know... do we want to have it as a separate patch?
>>>> may be we can fold it into some other patch someday later.
>>>
>>> Xishi spent his time to make the patch(review,create/send). And I want to
>>> give a credit to him. :)
>>
>> sure, I didn't mean "let's seize the credit" :)  my reasoning was
>> that that patch hardly can be counted even as trivial. per
>> documentation:
>>
>> : Trivial patches must qualify for one of the following rules:
>> :
>> : - Spelling fixes in documentation
>> : - Spelling fixes for errors which could break :manpage:`grep(1)`
>> : - Warning fixes (cluttering with useless warnings is bad)
>> : - Compilation fixes (only if they are actually correct)
>> : - Runtime fixes (only if they actually fix things)
>> : - Removing use of deprecated functions/macros
>> : - Contact detail and documentation fixes
>> : - Non-portable code replaced by portable code (even in arch-specific,
>> :   since people copy, as long as it's trivial)
>> : - Any fix by the author/maintainer of the file (ie. patch monkey
>> :   in re-transmission mode)
>>
>>
>> hence was my question. we can have it as "p.s. in this patch we also
>> remove XYZ reported by Xishi Qiu".
>>
>> but up to you.
>>
>>
>>
>> for instance, we can have Xishi's fix up as part of this "fix documentation
>> typos" patch. which can be counted in as trivial.
> 
> Xishi, Could you send your patch with fixing ones Sergey pointed out
> if Sergey doesn't mind?
> 
> You should include Sergey's SOB, too.
> 

Hi, Minchan and Sergey,

OK, but I will have a vacation soon, so could you just add
that typo in your patch? or I will resend v3 several days later.

Thanks
Xishi Qiu

>>
>>
>> ---
>>
>> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
>> index 9cc3c0b2c2c1..af7cd90c26f7 100644
>> --- a/mm/zsmalloc.c
>> +++ b/mm/zsmalloc.c
>> @@ -25,7 +25,7 @@
>>   * Usage of struct page flags:
>>   *     PG_private: identifies the first component page
>>   *     PG_private2: identifies the last component page
>> - *     PG_owner_priv_1: indentifies the huge component page
>> + *     PG_owner_priv_1: identifies the huge component page
>>   *
>>   */
>>  
>> @@ -65,7 +65,7 @@
>>  #define ZS_ALIGN               8
>>  
>>  /*
>> - * A single 'zspage' is composed of up to 2^N discontiguous 0-order (single)
>> + * A single 'zspage' is composed of up to 2^N discontinuous 0-order (single)
> 
> Hmm, discontinuous is right?
> I'm not a native but discontiguos is wrong? "contiguous" was used mm part widely.
> 
> 
>>   * pages. ZS_MAX_ZSPAGE_ORDER defines upper limit on N.
>>   */
>>  #define ZS_MAX_ZSPAGE_ORDER 2
>> @@ -2383,7 +2383,7 @@ struct zs_pool *zs_create_pool(const char *name)
>>                 goto err;
>>  
>>         /*
>> -        * Iterate reversly, because, size of size_class that we want to use
>> +        * Iterate reversely, because, size of size_class that we want to use
>>          * for merging should be larger or equal to current size.
>>          */
>>         for (i = zs_size_classes - 1; i >= 0; i--) {
>>
>>
>> ---
>>
>> 	-ss
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 
> .
> 

[toc] | [prev] | [next] | [standalone]

#1548421

Hello,

On (12/29/16 18:34), Xishi Qiu wrote:
> Hi, Minchan and Sergey,
> 
> OK, but I will have a vacation soon, so could you just add
> that typo in your patch? or I will resend v3 several days later.

works for me. the patch is trivial, so I definitely can wait for v3.
if there is a chance to find additional trivial corrections/tweaks
then I wouldn't mind to include them into v3 as well. I just want
to keep the trivial patch flow at min level.

have a good vacation.

	-ss

[toc] | [prev] | [next] | [standalone]

#1548221 — [PATCH V2] mm: fix typo of cache_alloc_zspage()

Delete extra semicolon, it was introduced in
3783689 zsmalloc: introduce zspage structure

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
 mm/zsmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9cc3c0b..2d6c92e 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -364,7 +364,7 @@ static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
 {
 	return kmem_cache_alloc(pool->zspage_cachep,
 			flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
-};
+}
 
 static void cache_free_zspage(struct zs_pool *pool, struct zspage *zspage)
 {
-- 
1.8.3.1

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web