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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Nov 2015 16:36:36 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Kyeongdon Kim <kyeongdon.kim@....com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH 2/3] zram: try vmalloc() after kmalloc()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/