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) :
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
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) :
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
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 = ffc00219
>
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)
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 = ffc00219
>
> <4>[ 922.182980][7] KDKIM: zcomp_lz4_create: 24: ret =
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
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
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:
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
>> >>
>> >> When we're using LZ4 multi compression streams for zram
On 2015-11-30 오후 8:14, Sergey Senozhatsky wrote:
> On (11/30/15 19:42), kyeongdon.kim wrote:
> [..]
>> 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).
>
> what delay?
On (12/01/15 08:18), Minchan Kim wrote:
[..]
> > 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.
>
On (11/30/15 19:42), kyeongdon.kim wrote:
[..]
> 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).
what delay? how significant it is? do you see it in practice or it's
On 2015-11-30 오후 4:10, Minchan Kim wrote:
> On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
>> From: Kyeongdon Kim
>>
>> 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
On (12/01/15 08:18), Minchan Kim wrote:
[..]
> > 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.
>
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
>> >>
>> >> When we're using LZ4 multi
On 2015-11-30 오후 8:14, Sergey Senozhatsky wrote:
> On (11/30/15 19:42), kyeongdon.kim wrote:
> [..]
>> 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).
>
> what delay?
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
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
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:
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 = ffc00219
>
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 = ffc00219
>
> <4>[ 922.182980][7] KDKIM: zcomp_lz4_create: 24: ret =
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)
On (11/30/15 19:42), kyeongdon.kim wrote:
[..]
> 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).
what delay? how significant it is? do you see it in practice or it's
On 2015-11-30 오후 4:10, Minchan Kim wrote:
> On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
>> From: Kyeongdon Kim
>>
>> When we're using LZ4 multi compression streams for zram swap,
>> we found out page allocation failure message in system running test.
On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
> From: Kyeongdon Kim
>
> 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,
On Fri, Nov 27, 2015 at 01:10:49PM +0900, Sergey Senozhatsky wrote:
> From: Kyeongdon Kim
>
> 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
28 matches
Mail list logo