On Thu, Jul 21, 2016 at 12:34 AM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > On Wed, Jul 20, 2016 at 08:12:13PM +0200, Alexander Potapenko wrote: >> >>>>> It's easy to reproduce in my setup: virtual machine with some amount of >> >>>>> swap space and try allocate about the size of RAM in userspace (I used >> >>>>> usemem[1] for that). >> >> Am I understanding right that you're seeing allocation failures from >> the stack depot? How often do they happen? Are they reported under >> heavy load, or just when you boot the kernel? > > As I described, it happens under memory pressure. > >> Allocating with __GFP_NOWARN will help here, but I think we'd better >> figure out what's gone wrong. >> I've sent https://lkml.org/lkml/2016/7/14/566, which should reduce the >> stack depot's memory consumption, for review - can you see if the bug >> is still reproducible with that? > > I was not able to trigger the failure with the same test case. > Tested with v2 of the patch. When the allocation happens in IRQ handler, we try to be clever and cut everything below EOI, because the lower frames don't really matter, but prevent stack deduplication. But since the stack pointers aren't preserved in the stack trace, the only way to do so is to check whether each frame is an IRQ entry point. That patch adds several entry points to the .irqentry.text section, thus allowing the stack depot to filter them out as well. If that works for you, we'd better not add the __GFP_NOWARN flag - that way we'll be able to detect similar problems in the future. > (Links to http://lkml.kernel.org/ or other archive with message-id in url > is prefered. lkml.org is garbage) Does gmane.org work (e.g. http://article.gmane.org/gmane.linux.kernel/2266971) It is surprisingly tricky to figure out a message id from the subject. > -- > Kirill A. Shutemov -- 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href