Messages in this thread | | | Date | Tue, 24 Nov 2015 16:57:07 +0900 | From | Minchan Kim <> | Subject | Re: [PATCH 2/3] zram: try vmalloc() after kmalloc() |
| |
On Tue, Nov 24, 2015 at 04:36:36PM +0900, Sergey Senozhatsky wrote: > 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.
I think your claim make sense if the failure comes from high memory pressure but order-3 alloc failure even if there are lots of order-0 free pages in my experience is easy to encouter so I think it doesn't mean memory pressure but just memory fragmentation.
> > > > 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.
Thanks!
> > > > ... 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).
My speaking came from MM internal knowledge so I accept your concern. if you prefer like GFP_NOIO, I will use it in next spin which makes reader less confused. Thanks!
> > -ss
-- Kind regards, Minchan Kim
| |