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

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

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