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 X-Spam-Level: X-Spam-Status: No, score=-13.1 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26ACBC433E0 for ; Wed, 15 Jul 2020 03:18:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DA8C42070E for ; Wed, 15 Jul 2020 03:18:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="akw9OjR2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA8C42070E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 39EB46B0002; Tue, 14 Jul 2020 23:18:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 34EC16B0003; Tue, 14 Jul 2020 23:18:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 264926B0005; Tue, 14 Jul 2020 23:18:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 10A076B0002 for ; Tue, 14 Jul 2020 23:18:12 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9A9151EE6 for ; Wed, 15 Jul 2020 03:18:11 +0000 (UTC) X-FDA: 77038851582.26.wind48_58085b426ef6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 743C61804B65A for ; Wed, 15 Jul 2020 03:18:11 +0000 (UTC) X-HE-Tag: wind48_58085b426ef6 X-Filterd-Recvd-Size: 5565 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jul 2020 03:18:10 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id n5so1685607pgf.7 for ; Tue, 14 Jul 2020 20:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=5KxleiqhO438Yw0pyuHKnHMkR/3zpCV5E7Q9NwelAtc=; b=akw9OjR2LvYLo1bh4LM1jEECgd+bLitjGKapvws5FPiZgxAjExjRvj/2plh5pAMrwo 7Pfrj2VbZDl8XgTqSWgBfZPl9lUGBl3Tfr/jMJ44CWmu9JLKoiMyn2JZillYTtJONG6J 4dp6OIkfWRzMUxRMKUS+pyNHSCJYxbl/TDds58K5U63CWixLWzu8OTjdh1ngzF2gRyjN soOYyybbeZsYDSV0nGoWn/aMTRRRWPw9LQPFsM9ECQD3qjQ5KK2vDnqBWhzuXd/AMsnr 2CN1/1/xilJrkKs8CrKO9pIffX0maS0TAZZEaF+n/LxZsR5XCdUNCDsZwnffoVM3PPNr 5pYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=5KxleiqhO438Yw0pyuHKnHMkR/3zpCV5E7Q9NwelAtc=; b=Akj1qbDjK+aruXjhTDzWK4mdNlUn+c0bjS7n6XBVSa6Ntb0qCwQnSY0Eo15EHcBVAS aUfKiYs8+CMDzTD6lGJ/YLaptnGS4SpMS4qo96CKL2SpCsrOL+pxhB6mP1oQlctIvCpK HgVnUuEJX3lt95HvAgASz/OAoq3lircTyjY/aWaYgRy1Ad871jv5GfE7qofXsBntYORQ dYFyM/8SofsICUV24Yny6fTgzlx9OVZLN9phRxQDwSrIQEsL2P7O2yfUOKSbFHy4D8SO ijAm9x5xZ82TxmrXBmK7nGPhBOqsQScMxdqtl4Cn7V4zEJCSa4oGFBLaVHYREYvN8tZa rwbA== X-Gm-Message-State: AOAM531LVksO/5zDKW1x1cX/hm8+G5/G5J+zJDLb6vm0KgRqe2H/+dJQ M3BWSFpUGoPE+61hfvLH0Ih8wg== X-Google-Smtp-Source: ABdhPJwtVJv7z10fCaaNYOKqIv36dGVxJ8OaEZUctckkDZ7kDvEJINg+yCZvazCi5Nf7X4Q2XCtm1w== X-Received: by 2002:aa7:9d81:: with SMTP id f1mr6765126pfq.225.1594783089822; Tue, 14 Jul 2020 20:18:09 -0700 (PDT) Received: from [2620:15c:17:3:4a0f:cfff:fe51:6667] ([2620:15c:17:3:4a0f:cfff:fe51:6667]) by smtp.gmail.com with ESMTPSA id o4sm401884pjo.16.2020.07.14.20.18.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 20:18:09 -0700 (PDT) Date: Tue, 14 Jul 2020 20:18:08 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Yafang Shao cc: Michal Hocko , Tetsuo Handa , Andrew Morton , Johannes Weiner , Linux MM Subject: Re: [PATCH v2] memcg, oom: check memcg margin for parallel oom In-Reply-To: Message-ID: References: <1594735034-19190-1-git-send-email-laoar.shao@gmail.com> User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 743C61804B65A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.003387, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 15 Jul 2020, Yafang Shao wrote: > > It has successfully resolved it for several years in our kernel, we tried > > an approach similiar to yours but saw many instances where memcg oom kills > > continued to proceed even though the memcg information dumped to the > > kernel log showed memory available. > > > > If this was a page or two that became available due to memory freeing, > > it's not a significant difference. Instead, if this races with an oom > > notification and a process exiting or being SIGKILL'd, it becomes much > > harder to explain to a user why their process was oom killed when there > > are tens of megabytes of memory available as shown by the kernel log (the > > freeing/exiting happened during a particularly long iteration of processes > > attached to the memcg, for example). > > > > That's what motivated a change to moving this to out_of_memory() directly, > > we found that it prevented even more unnecessary oom kills, which is a > > very good thing. It may only be easily observable and make a significant > > difference at very large scale, however. > > > > Thanks for the clarification. > > If it is the race which causes this issue and we want to reduce the > race window, I don't know whether it is proper to check the memcg > margin in out_of_memory() or do it before calling do_send_sig_info(). > Because per my understanding, dump_header() always takes much more > time than select_bad_process() especially if there're slow consoles. > So the race might easily happen when doing dump_header() or dumping > other information, but if we check the memcg margin after dumping this > oom info, it would be strange to dump so much oom logs without killing > a process. > Absolutely correct :) In my proposed patch, we declare dump_header() as the "point of no return" since we don't want to dump oom kill information to the kernel log when nothing is actually killed. We could abort at the very last minute, as you mention, but I think that may have an adverse impact on anything that cares about that log message.