Received: by 10.223.185.116 with SMTP id b49csp2211958wrg; Thu, 15 Feb 2018 08:10:43 -0800 (PST) X-Google-Smtp-Source: AH8x225DJ1+hDG4rRWp5Mk7q1ovAmUiQh9A+GLZzNY3g6J7tHwEzC2C/amUrl0rB6zp19dZ754Zz X-Received: by 10.98.216.137 with SMTP id e131mr2702557pfg.17.1518711043185; Thu, 15 Feb 2018 08:10:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518711043; cv=none; d=google.com; s=arc-20160816; b=onOOReZMR45be+lV+4lkRyrGskJWlgPf6QzW2gxahPMlMt9hYZm0DcgKUiUU91knv6 aEWpZPm1j76jQAduGym5vrnYYhcwIFzmFNVDvRP6wdTVO/8JPeaaXPOs9ITc+qkIzdlh wbkSbY3eu0cvExFmB3j9q3A8Ao6cKq+tN5v10ILqBd3vjPnWOH5Dag6Iy0aRgbNLWFqB jpaWMl6UxmWHZaStEnbGDpXGExm+SEzLVnNPyKZnVaSxsBgSuaH/Hko7AQPmtMCubCLE rH0Id8GZ7gBkndTW/Fm8bOA1SfIGrGMK95oLLKmgq5H7HrUDksdw1EjvmebsLB8crJcS HO4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=mgFMwNTRwFHWqP3mnRt79NwsMLz1V3rEtdiuZVtkoLI=; b=R75424zVb0SAjeY0T2Izo8j7jj3EoBetLaArYbLHQR/EtpuzsDDCaeZCDCO5epxDMU f5XTZliVnNuAWDKlnJg6EIE7U31u3zu1w3yqEQx9E7A9msTGPXCYnHQtnnKUvfFWumzF lg7ryD+lCF+81A119+EAiKWJoYIOEdWPQPC00nT3BL7pHCvEtm/RkVFrE+cObKe4qega yKYX2P9OO+MjdV7v6NtcqTethk9Kx19I3L3npnvXHNYcuGNeab3LLEy2ZmZz8JsGwdBl 8TpO4xtngZXmzEcloZxO26T4I6veaC8qzk9/5MBt2h0JtXX9ESrn2uRI+GH6gTVXC1SH o5GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=b+fhOtDC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10si2740892pge.396.2018.02.15.08.10.26; Thu, 15 Feb 2018 08:10:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=b+fhOtDC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425498AbeBOQIw (ORCPT + 99 others); Thu, 15 Feb 2018 11:08:52 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:33253 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424477AbeBOQIp (ORCPT ); Thu, 15 Feb 2018 11:08:45 -0500 Received: by mail-io0-f196.google.com with SMTP id n7so1127267iob.0 for ; Thu, 15 Feb 2018 08:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=mgFMwNTRwFHWqP3mnRt79NwsMLz1V3rEtdiuZVtkoLI=; b=b+fhOtDCYCmTISIQ+A+W1lYESzX8QN8iVNXixIZyoX6NNviVlYhXVYpgfRmK0g0mch fywpeZsQTTs3KmURXgCFsLn93mEF6ZbSTxvAl1lcOr8SDg61cwdO40tarKLxqyqx2+IB U+CxS1a70/t0Z/CiFeIAAUJQUgZj83j9hGta/4nBISUpFGchxtOFsw4X9kbCorQrvTU3 G1nFs1f3m40w/6DxU5cWjI6OgpvhXJCNMK//bnBd5XHbmItn6zUAeUr+rUdCSwRltUtH +MtAJ19HyXxGQ1Q1NtRoKssgDYWQD8HZ1NYh+Zd1uy72cpubqV/2fwNywr2TrH2kP1Oz AuaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mgFMwNTRwFHWqP3mnRt79NwsMLz1V3rEtdiuZVtkoLI=; b=uj+R2z8d2UBxl5VW8cbSDfwFo0kkp2iEQmVkpQZQN24tyPzkgXcTzYO/RY7yPxkycg oiyYwU/lY0x1hbPkZ4B7DYpVCUisCPlO9vh1aULl8Mgft+gIWnHixbP80llil0abYHke xo95pDF8PnpTCi471BGTpyyGWyljGG511DJaMF7fmfHhbTSV8NFXc00DsnA4s5QjKmcN vX0saTFLFzsTqssm6hxPHwqfj8MUYeacTvP+Hp3NHtcIx/+jphh/g5JbTEDyCoUvitRo 7fhuN5ztLRHFid+A8h8qH5MvdeU5r0BRKNve2NifHsT7riN1J9k4A8Z5Siqg/jFxVkiE q1Sw== X-Gm-Message-State: APf1xPC29OAzfVFR9tNoBCV0JyD3zEZUUQej7tSnZmlGTYF5AIkaMdGr lrcYXp3aFLl8fhX5w09R4j4Za6VrLq4= X-Received: by 10.107.68.2 with SMTP id r2mr2129124ioa.21.1518710924835; Thu, 15 Feb 2018 08:08:44 -0800 (PST) Received: from localhost.attlocal.net (104-187-157-211.lightspeed.mdsnwi.sbcglobal.net. [104.187.157.211]) by smtp.gmail.com with ESMTPSA id l5sm1689313itl.7.2018.02.15.08.08.43 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 15 Feb 2018 08:08:44 -0800 (PST) From: Dennis Zhou To: Tejun Heo , Christoph Lameter Cc: Daniel Borkmann , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dennis Zhou Subject: [PATCH 0/3] percpu: introduce no retry semantics and gfp passthrough Date: Thu, 15 Feb 2018 10:08:13 -0600 Message-Id: X-Mailer: git-send-email 1.8.5.2 (Apple Git-48) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi everyone, The percpu memory using the valloc area based chunk allocator lazily populates chunks by first requesting the full virtual address space required for the chunk and subsequently adding pages as allocations come through. To ensure atomic allocations can succeed, a workqueue item is used to maintain a minimum number of empty pages. In certain scenarios, such as reported in [1], it is possible that physical memory becomes quite scarce which can result in either a rather long time spent trying to find free pages or worse, a kernel panic. This patchset introduces no retry semantics to percpu memory by allowing users to pass through certain flags controlled by a whitelist. In this case, only __GFP_NORETRY and __GFP_NOWARN are initially allowed. This should prevent the eventual kernel panic due to the workqueue item and now give flexibility to users to decide how they want to fail when the percpu allocator fails if they use the additional flags. This does not prevent the allocator from panicking should an allocation without the additional flags cause an underlying allocator to trigger out of memory. I tested this by running basic allocations with and without passing the additional flags. Allocations are able to proceed / fail as expected without triggering the out of memory kernel panic. I still saw OOM killer activate, but I attribute that to other programs faulting in the background. Without the flags, the kernel panics pretty quickly with the expected out of memory panic. [1] https://lkml.org/lkml/2018/2/12/551 This patchset contains the following 3 patches: 0001-percpu-match-chunk-allocator-declarations-with-defin.patch 0002-percpu-add-__GFP_NORETRY-semantics-to-the-percpu-bal.patch 0003-percpu-allow-select-gfp-to-be-passed-to-underlying-a.patch 0001 fixes out of sync declaration and definiton variable names. 0002 adds no retry semantics to the workqueue balance path. 0003 enables users to pass through flags to the underlying percpu memory allocators. This also cleans up the semantics surrounding how the flags are managed. This patchset is ontop of percpu#master 7928b2cbe5. diffstats below: Dennis Zhou (3): percpu: match chunk allocator declarations with definitions percpu: add __GFP_NORETRY semantics to the percpu balancing path percpu: allow select gfp to be passed to underlying allocators mm/percpu-km.c | 8 ++++---- mm/percpu-vm.c | 18 +++++++++++------- mm/percpu.c | 52 ++++++++++++++++++++++++++++++++++------------------ 3 files changed, 49 insertions(+), 29 deletions(-) Thanks, Dennis