From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1759CC00528 for ; Wed, 26 Jul 2023 23:38:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230307AbjGZXiX (ORCPT ); Wed, 26 Jul 2023 19:38:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229587AbjGZXiV (ORCPT ); Wed, 26 Jul 2023 19:38:21 -0400 Received: from out-24.mta0.migadu.com (out-24.mta0.migadu.com [91.218.175.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 674A9E4C for ; Wed, 26 Jul 2023 16:38:20 -0700 (PDT) Date: Wed, 26 Jul 2023 16:38:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1690414697; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sTgnN9ZeCU8wiDSONMF29b7WeR8DaW8U9oGN1VLWAJs=; b=NKW2MrgmXsiJppIB+OLNLxajVnmn+Wn5652O4+9iPCMbNLfO9dfUZsiagbuZOLok2qQJd9 2izmMoBxHggaEFQA/W2ge7sIuH9TkPVxiemOIw1hlnnIwzW1ekv+YEOqcexDHJUYLvy8JI 7U0MNYy1bnE1GTqd1+27kUraNH7oNuw= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Rik van Riel , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: page_alloc: consume available CMA space first Message-ID: References: <20230726145304.1319046-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230726145304.1319046-1-hannes@cmpxchg.org> X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 26, 2023 at 10:53:04AM -0400, Johannes Weiner wrote: > On a memcache setup with heavy anon usage and no swap, we routinely > see premature OOM kills with multiple gigabytes of free space left: > > Node 0 Normal free:4978632kB [...] free_cma:4893276kB > > This free space turns out to be CMA. We set CMA regions aside for > potential hugetlb users on all of our machines, figuring that even if > there aren't any, the memory is available to userspace allocations. > > When the OOMs trigger, it's from unmovable and reclaimable allocations > that aren't allowed to dip into CMA. The non-CMA regions meanwhile are > dominated by the anon pages. > > > Because we have more options for CMA pages, change the policy to > always fill up CMA first. This reduces the risk of premature OOMs. I suspect it might cause regressions on small(er) devices where a relatively small cma area (Mb's) is often reserved for a use by various device drivers, which can't handle allocation failures well (even interim allocation failures). A startup time can regress too: migrating pages out of cma will take time. And given the velocity of kernel upgrades on such devices, we won't learn about it for next couple of years. > Movable pages can be migrated out of CMA when necessary, but we don't > have a mechanism to migrate them *into* CMA to make room for unmovable > allocations. The only recourse we have for these pages is reclaim, > which due to a lack of swap is unavailable in our case. Idk, should we introduce such a mechanism? Or use some alternative heuristics, which will be a better compromise between those who need cma allocations always pass and those who use large cma areas for opportunistic huge page allocations. Of course, we can add a boot flag/sysctl/per-cma-area flag, but I doubt we want really this. Thanks!