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


Groups > linux.kernel > #1276108

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

From Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()
Date 2015-11-24 08:40 +0100
Message-ID <qygmK-558-7@gated-at.bofh.it> (permalink)
References <qyd5v-33y-3@gated-at.bofh.it> <qyf7k-4lL-3@gated-at.bofh.it> <qyfTI-4UT-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On (11/24/15 16:03), Minchan Kim wrote:
> 
> Good question.
> 
> Actually, failure of allocation came from backend->create as Kyeongdon's
> comment because it requires order-3 allocation which is very fragile
> in embedded system recenlty(Android, webOS. That's why Joonsoo are solving
> the trouble by fixing compaction part). Otherwise, other kmalloc/vmalloc
> stuff in our example would be almost no trouble in real practice(Of course,
> if you says it might, you're absolutely right. It could fail but I think
> it's *really* rare in real practice).
> 
> More concern is order-1 allocation rather than kmalloc/vmalloc.
> I've got lots of allocation failure reports from product team until now
> and frankly speaking, I don't get such order-1 fail report until now.
> I guess the reason is that system is almost trobule due to heavy fragmentation
> before the notice such failure.
> 
> So, I think if we solve order-3 allocation in backend->create,
> above problem will be almost solved.

hm, ok, may be.
but the question whether we want to waste pages on additional streams
(especially, e.g. if we already have, say, 10 streams) is still valid.
a more intuitive here is to release some unneeded streams, not to increase
our pressure allocating new ones. well, at least it seems to be so.
those pages can be used by zsmalloc, for example.

> > and I'd prefer it to be a bit different -- use likely path first and
> > avoid an assignment in unlikely path.
> 
> Personally, I like one return case unless other is really better for
> performance. I have trained it for Andrew, I belive. :)
> But if you don't like this by performance reason, I will add unlikely
> for vmalloc path. If you hate it just by personal preferenece, please
> I want to stick my code.

no, I don't hate it.

> > ... and add GFP_NOIO to both kzalloc() and __vmalloc().
> 
> I can add it. The harmness is really ignorable but as I mentioned
> at reply of Andrew, what's the benefit with GFP_NOIO?
> We couldn't make forward progress with __GFP_RECLAIM in reclaim
> context.

aha, I probably missed that out.
(well, and, technically, things can change).

	-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/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams Minchan Kim <minchan@kernel.org> - 2015-11-24 05:10 +0100
  [RFC 3/3] zram: pass gfp from zcomp frontend to backend Minchan Kim <minchan@kernel.org> - 2015-11-24 05:10 +0100
  [PATCH 2/3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 05:10 +0100
  Re: [PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 07:00 +0100
    Re: [PATCH 1/3] zram/zcomp: use GFP_NOIO to allocate streams Minchan Kim <minchan@kernel.org> - 2015-11-24 08:20 +0100
  Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 07:20 +0100
    Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 07:50 +0100
      Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 08:10 +0100
    Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 08:10 +0100
      Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 08:40 +0100
        Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 09:00 +0100
          Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2015-11-24 09:10 +0100
            Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() Minchan Kim <minchan@kernel.org> - 2015-11-24 09:20 +0100

csiph-web