Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753525AbcCJQ6t (ORCPT ); Thu, 10 Mar 2016 11:58:49 -0500 Received: from mail-lb0-f177.google.com ([209.85.217.177]:34318 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750903AbcCJQ6l convert rfc822-to-8bit (ORCPT ); Thu, 10 Mar 2016 11:58:41 -0500 MIME-Version: 1.0 In-Reply-To: References: <00e9fa7d4adeac2d37a42cf613837e74850d929a.1456504662.git.glider@google.com> <56D471F5.3010202@gmail.com> <56D58398.2010708@gmail.com> Date: Thu, 10 Mar 2016 19:58:37 +0300 Message-ID: Subject: Re: [PATCH v4 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB From: Andrey Ryabinin To: Alexander Potapenko Cc: Dmitry Vyukov , Andrey Konovalov , Christoph Lameter , Andrew Morton , Steven Rostedt , Joonsoo Kim , JoonSoo Kim , Kostya Serebryany , kasan-dev , LKML , "linux-mm@kvack.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2613 Lines: 63 2016-03-08 14:42 GMT+03:00 Alexander Potapenko : > On Tue, Mar 1, 2016 at 12:57 PM, Andrey Ryabinin wrote: >>>> >>>>> + page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER); >>>> >>>> STACK_ALLOC_ORDER = 4 - that's a lot. Do you really need that much? >>> >>> Part of the issue the atomic context above. When we can't allocate >>> memory we still want to save the stack trace. When we have less than >>> STACK_ALLOC_ORDER memory, we try to preallocate another >>> STACK_ALLOC_ORDER in advance. So in the worst case, we have >>> STACK_ALLOC_ORDER memory and that should be enough to handle all >>> kmalloc/kfree in the atomic context. 1 page does not look enough. I >>> think Alex did some measuring of the failure race (when we are out of >>> memory and can't allocate more). >>> >> >> A lot of 4-order pages will lead to high fragmentation. You don't need physically contiguous memory here, >> so try to use vmalloc(). It is slower, but fragmentation won't be problem. > I've tried using vmalloc(), but turned out it's calling KASAN hooks > again. Dealing with reentrancy in this case sounds like an overkill. We'll have to deal with recursion eventually. Using stackdepot for page owner will cause recursion. > Given that we only require 9 Mb most of the time, is allocating > physical pages still a problem? > This is not about size, this about fragmentation. vmalloc allows to utilize available low-order pages, hence reduce the fragmentation. >> And one more thing. Take a look at mempool, because it's generally used to solve the problem you have here >> (guaranteed allocation in atomic context). > As far as I understood the docs, mempools have a drawback of > allocating too much memory which won't be available for any other use. As far as I understood your code, it has a drawback of allocating too much memory which won't be available for any other use ;) However, now I think that mempool doesn't fit here. We never free memory => never return it to pool. And this will cause 5sec delays between allocation retries in mempool_alloc(). > O'Reily's "Linux Device Drivers" even suggests not using mempools in > any case when it's easier to deal with allocation failures (that > advice is for device drivers, not sure if that stands for other > subsystems though). > > > -- > Alexander Potapenko > Software Engineer > > Google Germany GmbH > Erika-Mann-Straße, 33 > 80636 München > > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg