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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 487CBC433F5 for ; Fri, 29 Oct 2021 13:38:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D6EBB61181 for ; Fri, 29 Oct 2021 13:38:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D6EBB61181 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 35F3D6B0071; Fri, 29 Oct 2021 09:38:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E7C2940007; Fri, 29 Oct 2021 09:38:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 188F56B0073; Fri, 29 Oct 2021 09:38:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id DF0AB6B0071 for ; Fri, 29 Oct 2021 09:38:02 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5742231E47 for ; Fri, 29 Oct 2021 13:38:02 +0000 (UTC) X-FDA: 78749578404.15.0888D3E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf03.hostedemail.com (Postfix) with ESMTP id 0902230000AA for ; Fri, 29 Oct 2021 13:37:56 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A84291FD51; Fri, 29 Oct 2021 13:38:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1635514680; h=from:from:reply-to: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=a8JI0QNRAzRdW2vSpfFXA3jHxCxDzKPp/XFii33j1p0=; b=rjIAggCTn0dwW7XnW76Hrn0z+Bv90H/sFWo7kH8OIDWF/8pEwg0xJOV1pigQRE7+hHaB19 63XDMaOBAVX/CPjdeE3cLkMp5zXft+dw/Wlu8SFozl70kA2JS4+LPAglNA1k695T9fdhRR IeD4C7ektK64mOBkZ9DrneibPBuAc0Q= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 76F94A3B83; Fri, 29 Oct 2021 13:38:00 +0000 (UTC) Date: Fri, 29 Oct 2021 15:38:00 +0200 From: Michal Hocko To: Ning Zhang Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Vladimir Davydov , Yu Zhao Subject: Re: [RFC 0/6] Reclaim zero subpages of thp to avoid memory bloat Message-ID: References: <1635422215-99394-1-git-send-email-ningzhang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1635422215-99394-1-git-send-email-ningzhang@linux.alibaba.com> X-Stat-Signature: qiiqnofrp19rnksnpmiri7ctat8ci84o Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rjIAggCT; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0902230000AA X-HE-Tag: 1635514676-625702 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 28-10-21 19:56:49, Ning Zhang wrote: > As we know, thp may lead to memory bloat which may cause OOM. > Through testing with some apps, we found that the reason of > memory bloat is a huge page may contain some zero subpages > (may accessed or not). And we found that most zero subpages > are centralized in a few huge pages. > > Following is a text_classification_rnn case for tensorflow: > > zero_subpages huge_pages waste > [ 0, 1) 186 0.00% > [ 1, 2) 23 0.01% > [ 2, 4) 36 0.02% > [ 4, 8) 67 0.08% > [ 8, 16) 80 0.23% > [ 16, 32) 109 0.61% > [ 32, 64) 44 0.49% > [ 64, 128) 12 0.30% > [ 128, 256) 28 1.54% > [ 256, 513) 159 18.03% > > In the case, there are 187 huge pages (25% of the total huge pages) > which contain more then 128 zero subpages. And these huge pages > lead to 19.57% waste of the total rss. It means we can reclaim > 19.57% memory by splitting the 187 huge pages and reclaiming the > zero subpages. What is the THP policy configuration in your testing? I assume you are using defaults right? That would be always for THP and madvise for defrag. Would it make more sense to use madvise mode for THP for your workload? The THP code is rather complex and just by looking at the diffstat this add quite a lot on top. Is this really worth it? -- Michal Hocko SUSE Labs