On (11/24/15 13:13), Minchan Kim wrote:
> First of all, Thanks for the summary and proposal.
sure :)
> I think GFP_NOIO critical part(ie, your lockdep fix patch) should
> go to -stable so it should stand alone.
>
> About vmalloc, I like that. Just problem was gfp and we can
> pass it from upper
Hi Sergey,
On Tue, Nov 24, 2015 at 10:29:27AM +0900, Sergey Senozhatsky wrote:
> Cc Kyeongdon
>
> On (11/23/15 16:47), Andrew Morton wrote:
> [..]
> >
> > Doesn't make a lot of sense to me. We use a weakened gfp for the
> > kmalloc and if that fails, fall into vmalloc() using the stronger gfp
Cc Kyeongdon
On (11/23/15 16:47), Andrew Morton wrote:
[..]
>
> Doesn't make a lot of sense to me. We use a weakened gfp for the
> kmalloc and if that fails, fall into vmalloc() using the stronger gfp
> anyway.
Sir, you are right. that was "fixed" in my patch (but I definitely should
have been
On Tue, 24 Nov 2015 09:30:27 +0900 Sergey Senozhatsky
wrote:
> On (11/23/15 15:18), Andrew Morton wrote:
> [..]
> > > --- a/drivers/block/zram/zcomp_lz4.c
> > > +++ b/drivers/block/zram/zcomp_lz4.c
> > > @@ -20,10 +20,13 @@ static void *zcomp_lz4_create(void)
> > > void *ret;
> > >
> > >
On (11/23/15 15:18), Andrew Morton wrote:
[..]
> > --- a/drivers/block/zram/zcomp_lz4.c
> > +++ b/drivers/block/zram/zcomp_lz4.c
> > @@ -20,10 +20,13 @@ static void *zcomp_lz4_create(void)
> > void *ret;
> >
> > ret = kzalloc(LZ4_MEM_COMPRESS,
> > -
Hello Sergey,
On Mon, Nov 23, 2015 at 10:27:59PM +0900, Sergey Senozhatsky wrote:
> We can end up allocating a new compression stream with GFP_KERNEL
> from within the IO path, which may result is nested (recursive) IO
> operations. That can introduce problems if the IO path in question
> is a
On Mon, 23 Nov 2015 22:27:59 +0900 Sergey Senozhatsky
wrote:
> We can end up allocating a new compression stream with GFP_KERNEL
> from within the IO path, which may result is nested (recursive) IO
> operations. That can introduce problems if the IO path in question
> is a reclaimer, holding
We can end up allocating a new compression stream with GFP_KERNEL
from within the IO path, which may result is nested (recursive) IO
operations. That can introduce problems if the IO path in question
is a reclaimer, holding some locks that will deadlock nested IOs.
Allocate streams and working
We can end up allocating a new compression stream with GFP_KERNEL
from within the IO path, which may result is nested (recursive) IO
operations. That can introduce problems if the IO path in question
is a reclaimer, holding some locks that will deadlock nested IOs.
Allocate streams and working
Hello Sergey,
On Mon, Nov 23, 2015 at 10:27:59PM +0900, Sergey Senozhatsky wrote:
> We can end up allocating a new compression stream with GFP_KERNEL
> from within the IO path, which may result is nested (recursive) IO
> operations. That can introduce problems if the IO path in question
> is a
On Mon, 23 Nov 2015 22:27:59 +0900 Sergey Senozhatsky
wrote:
> We can end up allocating a new compression stream with GFP_KERNEL
> from within the IO path, which may result is nested (recursive) IO
> operations. That can introduce problems if the IO path in
On (11/24/15 13:13), Minchan Kim wrote:
> First of all, Thanks for the summary and proposal.
sure :)
> I think GFP_NOIO critical part(ie, your lockdep fix patch) should
> go to -stable so it should stand alone.
>
> About vmalloc, I like that. Just problem was gfp and we can
> pass it from upper
Hi Sergey,
On Tue, Nov 24, 2015 at 10:29:27AM +0900, Sergey Senozhatsky wrote:
> Cc Kyeongdon
>
> On (11/23/15 16:47), Andrew Morton wrote:
> [..]
> >
> > Doesn't make a lot of sense to me. We use a weakened gfp for the
> > kmalloc and if that fails, fall into vmalloc() using the stronger gfp
On (11/23/15 15:18), Andrew Morton wrote:
[..]
> > --- a/drivers/block/zram/zcomp_lz4.c
> > +++ b/drivers/block/zram/zcomp_lz4.c
> > @@ -20,10 +20,13 @@ static void *zcomp_lz4_create(void)
> > void *ret;
> >
> > ret = kzalloc(LZ4_MEM_COMPRESS,
> > -
Cc Kyeongdon
On (11/23/15 16:47), Andrew Morton wrote:
[..]
>
> Doesn't make a lot of sense to me. We use a weakened gfp for the
> kmalloc and if that fails, fall into vmalloc() using the stronger gfp
> anyway.
Sir, you are right. that was "fixed" in my patch (but I definitely should
have been
On Tue, 24 Nov 2015 09:30:27 +0900 Sergey Senozhatsky
wrote:
> On (11/23/15 15:18), Andrew Morton wrote:
> [..]
> > > --- a/drivers/block/zram/zcomp_lz4.c
> > > +++ b/drivers/block/zram/zcomp_lz4.c
> > > @@ -20,10 +20,13 @@ static void *zcomp_lz4_create(void)
16 matches
Mail list logo