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

Groups > linux.kernel > #1280502 > unrolled thread

Re: Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc()

Started by"kyeongdon.kim" <kyeongdon.kim@lge.com>
First post2015-12-01 03:40 +0100
Last post2015-12-01 08:30 +0100
Articles 9 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() "kyeongdon.kim" <kyeongdon.kim@lge.com> - 2015-12-01 03:40 +0100
    Re: Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-12-01 05:50 +0100
      Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-12-01 06:20 +0100
        Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Kyeongdon Kim <kyeongdon.kim@lge.com> - 2015-12-01 07:40 +0100
          Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-12-01 08:20 +0100
            Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-12-01 08:40 +0100
            Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-12-01 09:20 +0100
              Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-12-01 10:20 +0100
          Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-12-01 08:30 +0100

#1280502 — Re: Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc()

From"kyeongdon.kim" <kyeongdon.kim@lge.com>
Date2015-12-01 03:40 +0100
SubjectRe: Re: Re: [PATCH v3 2/2] zram: try vmalloc() after kmalloc()
Message-ID<qAJ1f-3y3-7@gated-at.bofh.it>
On 2015-12-01 오전 8:18, Minchan Kim wrote:
> Hi Kyeongdon,
> 
> On Mon, Nov 30, 2015 at 07:42:02PM +0900, kyeongdon.kim wrote:
> 
>> > On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
>> >> From: Kyeongdon Kim <kyeongdon.kim@lge.com>
>> >>
>> >> When we're using LZ4 multi compression streams for zram swap,
>> >> we found out page allocation failure message in system running test.
>> >> That was not only once, but a few(2 - 5 times per test).
>> >> Also, some failure cases were continually occurring to try allocation
>> >> order 3.
>> >>
>> >> In order to make parallel compression private data, we should call
>> >> kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
>> >> 2/3 size memory to allocate in that time, page allocation fails.
>> >> This patch makes to use vmalloc() as fallback of kmalloc(), this
>> >> prevents page alloc failure warning.
>> >>
>> >> After using this, we never found warning message in running test, also
>> >> It could reduce process startup latency about 60-120ms in each case.
>> >>
>> >> For reference a call trace :
>> >>
>> >> Binder_1: page allocation failure: order:3, mode:0x10c0d0
>> >> CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty
>> > #20
>> >> Call trace:
>> >> [<ffffffc0002069c8>] dump_backtrace+0x0/0x270
>> >> [<ffffffc000206c48>] show_stack+0x10/0x1c
>> >> [<ffffffc000cb51c8>] dump_stack+0x1c/0x28
>> >> [<ffffffc0002bbfc8>] warn_alloc_failed+0xfc/0x11c
>> >> [<ffffffc0002bf518>] __alloc_pages_nodemask+0x724/0x7f0
>> >> [<ffffffc0002bf5f8>] __get_free_pages+0x14/0x5c
>> >> [<ffffffc0002ed6a4>] kmalloc_order_trace+0x38/0xd8
>> >> [<ffffffc0005d9738>] zcomp_lz4_create+0x2c/0x38
>> >> [<ffffffc0005d78f0>] zcomp_strm_alloc+0x34/0x78
>> >> [<ffffffc0005d7a58>] zcomp_strm_multi_find+0x124/0x1ec
>> >> [<ffffffc0005d7c14>] zcomp_strm_find+0xc/0x18
>> >> [<ffffffc0005d8fa0>] zram_bvec_rw+0x2fc/0x780
>> >> [<ffffffc0005d9680>] zram_make_request+0x25c/0x2d4
>> >> [<ffffffc00040f8ac>] generic_make_request+0x80/0xbc
>> >> [<ffffffc00040f98c>] submit_bio+0xa4/0x15c
>> >> [<ffffffc0002e8bb0>] __swap_writepage+0x218/0x230
>> >> [<ffffffc0002e8c04>] swap_writepage+0x3c/0x4c
>> >> [<ffffffc0002c7384>] shrink_page_list+0x51c/0x8d0
>> >> [<ffffffc0002c7e88>] shrink_inactive_list+0x3f8/0x60c
>> >> [<ffffffc0002c86c8>] shrink_lruvec+0x33c/0x4cc
>> >> [<ffffffc0002c8894>] shrink_zone+0x3c/0x100
>> >> [<ffffffc0002c8c10>] try_to_free_pages+0x2b8/0x54c
>> >> [<ffffffc0002bf308>] __alloc_pages_nodemask+0x514/0x7f0
>> >> [<ffffffc0002bf5f8>] __get_free_pages+0x14/0x5c
>> >> [<ffffffc0003446cc>] proc_info_read+0x50/0xe4
>> >> [<ffffffc0002f5204>] vfs_read+0xa0/0x12c
>> >> [<ffffffc0002f59c8>] SyS_read+0x44/0x74
>> >> DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
>> >> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
>> >>
>> >> [minchan: change vmalloc gfp and adding comment about gfp]
>> >> [sergey: tweak comments and styles]
>> >> Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
>> >> Signed-off-by: Minchan Kim <minchan@kernel.org>
>> >
>> > Kyeongdon, Could you test this patch on your device?
>> >
>> > Thanks.
>>
>> Sorry to have kept you waiting,
>> Obviously, I couldn't see allocation fail message with this patch.
>> But, there is something to make some delay(not sure yet this is normal).
> 
> You mean new changes makes start-up delay of your application sometime
> still,
> but not frequent like old?
> 
I couldn't see start-up delay during my test after this patch.
But, I checked the return value from alloc function like the below :

static void *zcomp_lz4_create(void)
<snip>
  ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
			__GFP_NOWARN | __GFP_NOMEMALLOC);
  printk("%s: %d: ret = %p\n",__func__,__LINE__,ret);	//line 32
  if (!ret) {
    ret = __vmalloc(LZ4_MEM_COMPRESS,
		GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN |
		__GFP_NOMEMALLOC | __GFP_ZERO | __GFP_HIGHMEM,
		PAGE_KERNEL);
    printk("%s: %d: ret = %p\n",__func__,__LINE__,ret);	//line 38
  }
  return ret;

log message :
[  352.226014][0] zcomp_lz4_create: 32: ret =           (null)
[  352.226035][0] zcomp_lz4_create: 38: ret =           (null)
[  352.226791][0] zcomp_lz4_create: 32: ret =           (null)
[  352.226809][0] zcomp_lz4_create: 38: ret =           (null)
[  352.230348][0] zcomp_lz4_create: 32: ret =           (null)
[  352.230369][0] zcomp_lz4_create: 38: ret =           (null)
[  352.230460][0] zcomp_lz4_create: 32: ret =           (null)
[  352.230485][0] zcomp_lz4_create: 38: ret =           (null)
[  352.230507][0] zcomp_lz4_create: 32: ret =           (null)
[  352.230520][0] zcomp_lz4_create: 38: ret =           (null)
[  352.230608][0] zcomp_lz4_create: 32: ret =           (null)
[  352.230619][0] zcomp_lz4_create: 38: ret =           (null)
[  352.230888][0] zcomp_lz4_create: 32: ret =           (null)
[  352.230902][0] zcomp_lz4_create: 38: ret =           (null)
[  352.231406][0] zcomp_lz4_create: 32: ret = ffffffc002088000
[  352.234024][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234060][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234359][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234384][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234618][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234639][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234667][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234685][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234738][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234748][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234800][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234816][0] zcomp_lz4_create: 38: ret =           (null)
[  352.234852][0] zcomp_lz4_create: 32: ret =           (null)
[  352.234865][0] zcomp_lz4_create: 38: ret =           (null)
[  352.235136][0] zcomp_lz4_create: 32: ret =           (null)
[  352.235179][0] zcomp_lz4_create: 38: ret = ffffff80016a4000

I thought this pattern from vmalloc is not normal.
>>
>> static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
>> {
>> <snip>
>>
>> zstrm->private = comp->backend->create();
>> ^ // sometimes, return 'null' continually(2-5times)
> 
> Hmm, I think it is caused by __GFP_NOMEMALLOC.
> Could you test it without the flag?
> 
>>
>> As you know, if there is 'null' return, this function is called again to
>> get a memory in while() loop. I just checked this one with printk().
>>
>> If you guys don't mind, I'll test more with trace log to check time
> delay.
> 
> No problem.
> 
>>
>> However, If this is fully expectable status to you.
>> I think I don't need to do it.
> 
> It's not what I expected. Actually, I thought failure of vmalloc
> in that place should be *really really* rare. I think it's caused by
> __GFP_NOMEMALLOC so I want to see test result without the flag.
> 
> Thanks for the careful test!
> 
You're welcome.

After I removed flag '__GFP_NOMEMALLOC', I couldn't find return 'null'
from vmalloc until now.

log message :
<4>[ 2288.954934][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
<4>[ 2288.954972][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff800287e000
..<snip>..
<4>[ 2289.092411][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
<4>[ 2289.092546][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028b5000
..<snip>..
<4>[ 2289.135628][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
<4>[ 2289.135642][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
<4>[ 2289.135729][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028be000
<4>[ 2289.135732][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028c7000

Thanks,
Kyeongdon Kim
> 
>>
>> Thanks,
>> Kyeongdon Kim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1280572

FromMinchan Kim <minchan@kernel.org>
Date2015-12-01 05:50 +0100
Message-ID<qAL34-4PG-3@gated-at.bofh.it>
In reply to#1280502
On Tue, Dec 01, 2015 at 11:31:41AM +0900, kyeongdon.kim wrote:
> On 2015-12-01 오전 8:18, Minchan Kim wrote:
> > Hi Kyeongdon,
> > 
> > On Mon, Nov 30, 2015 at 07:42:02PM +0900, kyeongdon.kim wrote:
> > 
> >> > On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
> >> >> From: Kyeongdon Kim <kyeongdon.kim@lge.com>
> >> >>
> >> >> When we're using LZ4 multi compression streams for zram swap,
> >> >> we found out page allocation failure message in system running test.
> >> >> That was not only once, but a few(2 - 5 times per test).
> >> >> Also, some failure cases were continually occurring to try allocation
> >> >> order 3.
> >> >>
> >> >> In order to make parallel compression private data, we should call
> >> >> kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
> >> >> 2/3 size memory to allocate in that time, page allocation fails.
> >> >> This patch makes to use vmalloc() as fallback of kmalloc(), this
> >> >> prevents page alloc failure warning.
> >> >>
> >> >> After using this, we never found warning message in running test, also
> >> >> It could reduce process startup latency about 60-120ms in each case.
> >> >>
> >> >> For reference a call trace :
> >> >>
> >> >> Binder_1: page allocation failure: order:3, mode:0x10c0d0
> >> >> CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty
> >> > #20
> >> >> Call trace:
> >> >> [<ffffffc0002069c8>] dump_backtrace+0x0/0x270
> >> >> [<ffffffc000206c48>] show_stack+0x10/0x1c
> >> >> [<ffffffc000cb51c8>] dump_stack+0x1c/0x28
> >> >> [<ffffffc0002bbfc8>] warn_alloc_failed+0xfc/0x11c
> >> >> [<ffffffc0002bf518>] __alloc_pages_nodemask+0x724/0x7f0
> >> >> [<ffffffc0002bf5f8>] __get_free_pages+0x14/0x5c
> >> >> [<ffffffc0002ed6a4>] kmalloc_order_trace+0x38/0xd8
> >> >> [<ffffffc0005d9738>] zcomp_lz4_create+0x2c/0x38
> >> >> [<ffffffc0005d78f0>] zcomp_strm_alloc+0x34/0x78
> >> >> [<ffffffc0005d7a58>] zcomp_strm_multi_find+0x124/0x1ec
> >> >> [<ffffffc0005d7c14>] zcomp_strm_find+0xc/0x18
> >> >> [<ffffffc0005d8fa0>] zram_bvec_rw+0x2fc/0x780
> >> >> [<ffffffc0005d9680>] zram_make_request+0x25c/0x2d4
> >> >> [<ffffffc00040f8ac>] generic_make_request+0x80/0xbc
> >> >> [<ffffffc00040f98c>] submit_bio+0xa4/0x15c
> >> >> [<ffffffc0002e8bb0>] __swap_writepage+0x218/0x230
> >> >> [<ffffffc0002e8c04>] swap_writepage+0x3c/0x4c
> >> >> [<ffffffc0002c7384>] shrink_page_list+0x51c/0x8d0
> >> >> [<ffffffc0002c7e88>] shrink_inactive_list+0x3f8/0x60c
> >> >> [<ffffffc0002c86c8>] shrink_lruvec+0x33c/0x4cc
> >> >> [<ffffffc0002c8894>] shrink_zone+0x3c/0x100
> >> >> [<ffffffc0002c8c10>] try_to_free_pages+0x2b8/0x54c
> >> >> [<ffffffc0002bf308>] __alloc_pages_nodemask+0x514/0x7f0
> >> >> [<ffffffc0002bf5f8>] __get_free_pages+0x14/0x5c
> >> >> [<ffffffc0003446cc>] proc_info_read+0x50/0xe4
> >> >> [<ffffffc0002f5204>] vfs_read+0xa0/0x12c
> >> >> [<ffffffc0002f59c8>] SyS_read+0x44/0x74
> >> >> DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
> >> >> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
> >> >>
> >> >> [minchan: change vmalloc gfp and adding comment about gfp]
> >> >> [sergey: tweak comments and styles]
> >> >> Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
> >> >> Signed-off-by: Minchan Kim <minchan@kernel.org>
> >> >
> >> > Kyeongdon, Could you test this patch on your device?
> >> >
> >> > Thanks.
> >>
> >> Sorry to have kept you waiting,
> >> Obviously, I couldn't see allocation fail message with this patch.
> >> But, there is something to make some delay(not sure yet this is normal).
> > 
> > You mean new changes makes start-up delay of your application sometime
> > still,
> > but not frequent like old?
> > 
> I couldn't see start-up delay during my test after this patch.
> But, I checked the return value from alloc function like the below :
> 
> static void *zcomp_lz4_create(void)
> <snip>
>   ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
> 			__GFP_NOWARN | __GFP_NOMEMALLOC);
>   printk("%s: %d: ret = %p\n",__func__,__LINE__,ret);	//line 32
>   if (!ret) {
>     ret = __vmalloc(LZ4_MEM_COMPRESS,
> 		GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN |
> 		__GFP_NOMEMALLOC | __GFP_ZERO | __GFP_HIGHMEM,
> 		PAGE_KERNEL);
>     printk("%s: %d: ret = %p\n",__func__,__LINE__,ret);	//line 38
>   }
>   return ret;

OK, I got it. 

> 
> log message :
> [  352.226014][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.226035][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.226791][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.226809][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.230348][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.230369][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.230460][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.230485][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.230507][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.230520][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.230608][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.230619][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.230888][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.230902][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.231406][0] zcomp_lz4_create: 32: ret = ffffffc002088000
> [  352.234024][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234060][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234359][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234384][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234618][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234639][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234667][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234685][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234738][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234748][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234800][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234816][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.234852][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.234865][0] zcomp_lz4_create: 38: ret =           (null)
> [  352.235136][0] zcomp_lz4_create: 32: ret =           (null)
> [  352.235179][0] zcomp_lz4_create: 38: ret = ffffff80016a4000
> 
> I thought this pattern from vmalloc is not normal.
> >>
> >> static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
> >> {
> >> <snip>
> >>
> >> zstrm->private = comp->backend->create();
> >> ^ // sometimes, return 'null' continually(2-5times)
> > 
> > Hmm, I think it is caused by __GFP_NOMEMALLOC.
> > Could you test it without the flag?
> > 
> >>
> >> As you know, if there is 'null' return, this function is called again to
> >> get a memory in while() loop. I just checked this one with printk().
> >>
> >> If you guys don't mind, I'll test more with trace log to check time
> > delay.
> > 
> > No problem.
> > 
> >>
> >> However, If this is fully expectable status to you.
> >> I think I don't need to do it.
> > 
> > It's not what I expected. Actually, I thought failure of vmalloc
> > in that place should be *really really* rare. I think it's caused by
> > __GFP_NOMEMALLOC so I want to see test result without the flag.
> > 
> > Thanks for the careful test!
> > 
> You're welcome.
> 
> After I removed flag '__GFP_NOMEMALLOC', I couldn't find return 'null'
> from vmalloc until now.
 
Thanks for the test.
You said you cannot see the delay any more so it's fine as it is.

Regardless of it, I want to remove __GFP_NOMEMALLOC in the gfp_mask.
The reason we decided to add vmalloc fallback is that we expect that
it is likely to succeed a few order-0 pages to allocate (sizeof(buffer)
> PAGE_SIZE) although it was failed by kmalloc.
But what I missing is that zram-swap is working in direct reclaim
normally so it is more flexible to use emegency memory pool(
e,g, zsmalloc doesn't use __GFP_NOMEMALLOC) so there is no point
to use __GFP_NOMEMALLOC in here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280575

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2015-12-01 06:20 +0100
Message-ID<qALw5-5g0-5@gated-at.bofh.it>
In reply to#1280572
On (12/01/15 13:55), Minchan Kim wrote:
[..]
> To clear my opinion,
> 
> lzo_create(gfp_t flags)
> {
>         void * ret = kmalloc(LZO1X_MEM_COMPRESS, flags);
>         if (!ret)
>                 ret = vmalloc(LZO1X_MEM_COMPRESS, flasgs | GFP_NOMEMALLOC);
>         return ret;
> }

ah, ok, I see. I've a question.

we had
	kmalloc(f | __GFP_NOMEMALLOC)
	__vmalloc(f | __GFP_NOMEMALLOC)

which produced high failure rates for both kmalloc() and __vmalloc()

test #1

> > > log message :
[..]
> > > [  352.230608][0] zcomp_lz4_create: 32: ret =           (null)
> > > [  352.230619][0] zcomp_lz4_create: 38: ret =           (null)
> > > [  352.230888][0] zcomp_lz4_create: 32: ret =           (null)
> > > [  352.230902][0] zcomp_lz4_create: 38: ret =           (null)
> > > [  352.231406][0] zcomp_lz4_create: 32: ret = ffffffc002088000
> > > [  352.234024][0] zcomp_lz4_create: 32: ret =           (null)
> > > [  352.234060][0] zcomp_lz4_create: 38: ret =           (null)
> > > [  352.234359][0] zcomp_lz4_create: 32: ret =           (null)
[..]
> > > [  352.234384][0] zcomp_lz4_create: 38: ret =           (null)
> > > [  352.234618][0] zcomp_lz4_create: 32: ret =           (null)
> > > [  352.234639][0] zcomp_lz4_create: 38: ret =           (null)
> > > [  352.234667][0] zcomp_lz4_create: 32: ret =           (null)
> > > [  352.235179][0] zcomp_lz4_create: 38: ret = ffffff80016a4000



Kyeongdon, do I understand correctly, that for the second test you
removed '__GFP_NOMEMALLOC' from both kmalloc() and __vmalloc()?

iow:
	kmalloc(f & ~__GFP_NOMEMALLOC)
	vmalloc(f & ~__GFP_NOMEMALLOC)

test #2 : almost always failing kmalloc() and !NULL __vmalloc()

> > > log message :
> > > <4>[ 2288.954934][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
> > > <4>[ 2288.954972][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff800287e000
> > > ..<snip>..
> > > <4>[ 2289.092411][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
> > > <4>[ 2289.092546][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028b5000
> > > ..<snip>..
> > > <4>[ 2289.135628][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
> > > <4>[ 2289.135642][0] KDKIM: zcomp_lz4_create: 24: ret =           (null)
> > > <4>[ 2289.135729][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028be000
> > > <4>[ 2289.135732][0] KDKIM: zcomp_lz4_create: 30: ret = ffffff80028c7000


if this is the case (__GFP_NOMEMALLOC removed from both kmalloc and __vmalloc),
then proposed

	kmalloc(f & ~__GFP_NOMEMALLOC)
	__vmalloc(f | __GFP_NOMEMALLOC)


can be very close to 'test #1 && test #2':

	kmalloc() fails (as in test #2)
	__vmalloc() fails (as in test #1)

isn't it?

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280594

FromKyeongdon Kim <kyeongdon.kim@lge.com>
Date2015-12-01 07:40 +0100
Message-ID<qAMLw-5Zu-5@gated-at.bofh.it>
In reply to#1280575
On 2015-12-01 오후 2:16, Sergey Senozhatsky wrote:
> On (12/01/15 13:55), Minchan Kim wrote:
> [..]
>> To clear my opinion,
>>
>> lzo_create(gfp_t flags)
>> {
>> void * ret = kmalloc(LZO1X_MEM_COMPRESS, flags);
>> if (!ret)
>> ret = vmalloc(LZO1X_MEM_COMPRESS, flasgs | GFP_NOMEMALLOC);
>> return ret;
>> }
> 
> ah, ok, I see. I've a question.
> 
> we had
> kmalloc(f | __GFP_NOMEMALLOC)
> __vmalloc(f | __GFP_NOMEMALLOC)
> 
> which produced high failure rates for both kmalloc() and __vmalloc()
> 
> test #1
> 
>> > > log message :
> [..]
>> > > [ 352.230608][0] zcomp_lz4_create: 32: ret = (null)
>> > > [ 352.230619][0] zcomp_lz4_create: 38: ret = (null)
>> > > [ 352.230888][0] zcomp_lz4_create: 32: ret = (null)
>> > > [ 352.230902][0] zcomp_lz4_create: 38: ret = (null)
>> > > [ 352.231406][0] zcomp_lz4_create: 32: ret = ffffffc002088000
>> > > [ 352.234024][0] zcomp_lz4_create: 32: ret = (null)
>> > > [ 352.234060][0] zcomp_lz4_create: 38: ret = (null)
>> > > [ 352.234359][0] zcomp_lz4_create: 32: ret = (null)
> [..]
>> > > [ 352.234384][0] zcomp_lz4_create: 38: ret = (null)
>> > > [ 352.234618][0] zcomp_lz4_create: 32: ret = (null)
>> > > [ 352.234639][0] zcomp_lz4_create: 38: ret = (null)
>> > > [ 352.234667][0] zcomp_lz4_create: 32: ret = (null)
>> > > [ 352.235179][0] zcomp_lz4_create: 38: ret = ffffff80016a4000
> 
> 
> 
> Kyeongdon, do I understand correctly, that for the second test you
> removed '__GFP_NOMEMALLOC' from both kmalloc() and __vmalloc()?
> 
> iow:
> kmalloc(f & ~__GFP_NOMEMALLOC)
> vmalloc(f & ~__GFP_NOMEMALLOC)
> 
> test #2 : almost always failing kmalloc() and !NULL __vmalloc()
> 
>> > > log message :
>> > > <4>[ 2288.954934][0] KDKIM: zcomp_lz4_create: 24: ret = (null)
>> > > <4>[ 2288.954972][0] KDKIM: zcomp_lz4_create: 30: ret =
> ffffff800287e000
>> > > ..<snip>..
>> > > <4>[ 2289.092411][0] KDKIM: zcomp_lz4_create: 24: ret = (null)
>> > > <4>[ 2289.092546][0] KDKIM: zcomp_lz4_create: 30: ret =
> ffffff80028b5000
>> > > ..<snip>..
>> > > <4>[ 2289.135628][0] KDKIM: zcomp_lz4_create: 24: ret = (null)
>> > > <4>[ 2289.135642][0] KDKIM: zcomp_lz4_create: 24: ret = (null)
>> > > <4>[ 2289.135729][0] KDKIM: zcomp_lz4_create: 30: ret =
> ffffff80028be000
>> > > <4>[ 2289.135732][0] KDKIM: zcomp_lz4_create: 30: ret =
> ffffff80028c7000
> 
> 
> if this is the case (__GFP_NOMEMALLOC removed from both kmalloc and
> __vmalloc),
> then proposed
> 
> kmalloc(f & ~__GFP_NOMEMALLOC)
> __vmalloc(f | __GFP_NOMEMALLOC)
> 
> 
> can be very close to 'test #1 && test #2':
> 
> kmalloc() fails (as in test #2)
> __vmalloc() fails (as in test #1)
> 
> isn't it?
> 
> -ss

Let me give you a simple code of it.

@test #1 (previous shared log)
 kmalloc(f | __GFP_NOMEMALLOC)
  __vmalloc(f | __GFP_NOMEMALLOC)
// can find failure both

@test #2 (previous shared log)
 kmalloc(f | __GFP_NOMEMALLOC)
__vmalloc(f) 	
// removed '__GFP_NOMEMALLOC' from vmalloc() only, and cannot find
failure from vmalloc()

And like you said, I made a quick check to see a failure about kmalloc()
without the flag :

@test #3
 kmalloc(f)
__vmalloc(f | __GFP_NOMEMALLOC)
// removed '__GFP_NOMEMALLOC' from zmalloc() only
// and cannot find failure from zmalloc(), but in this case, it's hard
to find failure from vmalloc() because of already allocation mostly from
zsmalloc()

log message (test #3) :
<4>[  186.763605][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002030000
<4>[  186.776652][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020f0000
<4>[  186.811423][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002108000
<4>[  186.816744][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002000000
<4>[  186.816796][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002008000

@test #4
 kmalloc(f)
__vmalloc(f)
// cannot find failure both until now

log message (test #4) :
<4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
<snip>
<4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
<snip>
<4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
<snip>
<4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000

So,is there another problem if we remove the flag from both sides?

Thanks,
Kyeongdon Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280606

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2015-12-01 08:20 +0100
Message-ID<qANoe-6v3-9@gated-at.bofh.it>
In reply to#1280594
On (12/01/15 15:35), Kyeongdon Kim wrote:
[..]
> @test #4
>  kmalloc(f)
> __vmalloc(f)
> // cannot find failure both until now
> 
> log message (test #4) :
> <4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
> <snip>
> <4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
> <snip>
> <4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
> <snip>
> <4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000

Thanks!

> So,is there another problem if we remove the flag from both sides?
> 

Technically, '~__GFP_NOMEMALLOC' is what we've been doing for some time (well,
always); and, as Minchan noted, zsmalloc does not depend on emergency pools.

I vote for removal of __GFP_NOMEMALLOC from both kmalloc() and __vmalloc().

(user can make ->max_strm big enough to deplete emergency mem; but I tend to
ignore it).

Minchan?

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280618

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2015-12-01 08:40 +0100
Message-ID<qANHz-6Cu-9@gated-at.bofh.it>
In reply to#1280606
On (12/01/15 16:15), Sergey Senozhatsky wrote:
> On (12/01/15 15:35), Kyeongdon Kim wrote:
> [..]
> > @test #4
> >  kmalloc(f)
> > __vmalloc(f)
> > // cannot find failure both until now
> > 
> > log message (test #4) :
> > <4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
> > <snip>
> > <4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
> > <snip>
> > <4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
> > <snip>
> > <4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000
> 
> Thanks!
> 
> > So,is there another problem if we remove the flag from both sides?
> > 
> 
> Technically, '~__GFP_NOMEMALLOC' is what we've been doing for some time (well,
> always); and, as Minchan noted, zsmalloc does not depend on emergency pools.
> 
> I vote for removal of __GFP_NOMEMALLOC from both kmalloc() and __vmalloc().
> 

um.. which is very close to
    "remove vmalloc() fallback and use kzalloc(f & ~__GFP_NOMEMALLOC) only"

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280631

FromMinchan Kim <minchan@kernel.org>
Date2015-12-01 09:20 +0100
Message-ID<qAOki-76n-9@gated-at.bofh.it>
In reply to#1280606
On Tue, Dec 01, 2015 at 04:15:42PM +0900, Sergey Senozhatsky wrote:
> On (12/01/15 15:35), Kyeongdon Kim wrote:
> [..]
> > @test #4
> >  kmalloc(f)
> > __vmalloc(f)
> > // cannot find failure both until now
> > 
> > log message (test #4) :
> > <4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
> > <snip>
> > <4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
> > <snip>
> > <4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
> > <snip>
> > <4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000
> 
> Thanks!
> 
> > So,is there another problem if we remove the flag from both sides?
> > 
> 
> Technically, '~__GFP_NOMEMALLOC' is what we've been doing for some time (well,
> always); and, as Minchan noted, zsmalloc does not depend on emergency pools.
> 
> I vote for removal of __GFP_NOMEMALLOC from both kmalloc() and __vmalloc().
> 
> (user can make ->max_strm big enough to deplete emergency mem; but I tend to
> ignore it).
> 
> Minchan?

Agree. Do you mind resending patches? :)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280666

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2015-12-01 10:20 +0100
Message-ID<qAPgl-7I5-7@gated-at.bofh.it>
In reply to#1280631
On (12/01/15 17:16), Minchan Kim wrote:
> On Tue, Dec 01, 2015 at 04:15:42PM +0900, Sergey Senozhatsky wrote:
> > On (12/01/15 15:35), Kyeongdon Kim wrote:
> > [..]
> > > @test #4
> > >  kmalloc(f)
> > > __vmalloc(f)
> > > // cannot find failure both until now
> > > 
> > > log message (test #4) :
> > > <4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
> > > <snip>
> > > <4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
> > > <snip>
> > > <4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
> > > <snip>
> > > <4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000
> > 
> > Thanks!
> > 
> > > So,is there another problem if we remove the flag from both sides?
> > > 
> > 
> > Technically, '~__GFP_NOMEMALLOC' is what we've been doing for some time (well,
> > always); and, as Minchan noted, zsmalloc does not depend on emergency pools.
> > 
> > I vote for removal of __GFP_NOMEMALLOC from both kmalloc() and __vmalloc().
> > 
> > (user can make ->max_strm big enough to deplete emergency mem; but I tend to
> > ignore it).
> > 
> > Minchan?
> 
> Agree. Do you mind resending patches? :)

OK, will do later today. Thanks.

	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280610

FromSergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date2015-12-01 08:30 +0100
Message-ID<qANxU-6yD-9@gated-at.bofh.it>
In reply to#1280594
On (12/01/15 15:35), Kyeongdon Kim wrote:
> Let me give you a simple code of it.
> 
> @test #1 (previous shared log)
>  kmalloc(f | __GFP_NOMEMALLOC)
>   __vmalloc(f | __GFP_NOMEMALLOC)
> // can find failure both
> 
> @test #2 (previous shared log)
>  kmalloc(f | __GFP_NOMEMALLOC)
> __vmalloc(f) 	
> // removed '__GFP_NOMEMALLOC' from vmalloc() only, and cannot find
> failure from vmalloc()
> 
> And like you said, I made a quick check to see a failure about kmalloc()
> without the flag :
> 
> @test #3
>  kmalloc(f)
> __vmalloc(f | __GFP_NOMEMALLOC)
> // removed '__GFP_NOMEMALLOC' from zmalloc() only
> // and cannot find failure from zmalloc(), but in this case, it's hard
> to find failure from vmalloc() because of already allocation mostly from
> zsmalloc()
> 

I assume, that "zsmalloc" and "zmalloc" here are meant to be "kzalloc (kmalloc)"

	-ss

> log message (test #3) :
> <4>[  186.763605][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002030000
> <4>[  186.776652][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020f0000
> <4>[  186.811423][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002108000
> <4>[  186.816744][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002000000
> <4>[  186.816796][1] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002008000
> 
> @test #4
>  kmalloc(f)
> __vmalloc(f)
> // cannot find failure both until now
> 
> log message (test #4) :
> <4>[  641.440468][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002190000
> <snip>
> <4>[  922.182980][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002208000
> <snip>
> <4>[  923.197593][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc002020000
> <snip>
> <4>[  939.813499][7] KDKIM: zcomp_lz4_create: 24: ret = ffffffc0020a0000
> 
> So,is there another problem if we remove the flag from both sides?
> 
> Thanks,
> Kyeongdon Kim
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web