From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 829EB33DEDB for ; Fri, 16 Jan 2026 15:55:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768578933; cv=none; b=UvRkpDFZp4RbBVSRJeAXSPccyOOApKybqKsC1mwgI/SneZCA1JK0SL04WKMtyDyBZMAB/8FyOxbxsTExcLqKDJ8+mcmCy5dipkCNo18q/Jp2r5m2RpKrA1nzU9BHP/Rsx38zDT9bplQ/3XK5NO0bTuiBd1GyR2lrmlZmhAcvfT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768578933; c=relaxed/simple; bh=gYRLTx/x34zgvDGr8Ikg/savTmJY601nWRaB0KVkXwA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=am9B/df2ZRQbm03Oc/bvRdzXEXcDN30NNyrq29W5cEz4G49jhcQ8I1ZL2r+7xSWzwin8s7MmRDiEjtVMyaNlLmmG7Z3qP20rSHluJO+Vqw8dl5HUf9crBgol1vWBed53pfeNFBHyUwVwOQc+0Y3cwxEeUR4IEoLM/BGFNZ9QW74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=NE8FiOyk; arc=none smtp.client-ip=209.85.128.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="NE8FiOyk" Received: by mail-wm1-f65.google.com with SMTP id 5b1f17b1804b1-4801c314c84so11610025e9.0 for ; Fri, 16 Jan 2026 07:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1768578927; x=1769183727; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nC1t8XaX/bq14ENSBQ5Fda7IB2vEXwzrtJEP49kE9AQ=; b=NE8FiOykdnhDOMKOtxxcUZ2A8byokPHbFAfOK5GO64nMeeDvjWiq0bsUAyJ+jngW2m /Jpa3fuCUlDE5b7mlmdpT1GsZTogNatJk/18TC/8ukSAFpoQUCp2/V1VnrahOPuT6MlP ReKNrOHjA5ANiRTgGGMAXYGEnEZ/uOVZCHw1VErcWhRQl1GkgDklJOo+5VCnFTMd/OJX nPiqrQh/aESx3YtVefF0ktumIfI5gkNbAt1wL69LJFL4G5z7P3QA233hJPwsoxK9bbcc pq2Yd/uPVv6ReSJXp49ygr+FPjazMwO53m+ZQjR9KeDTskpI/efYkchFs1ERb0k/c5fs qQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768578927; x=1769183727; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nC1t8XaX/bq14ENSBQ5Fda7IB2vEXwzrtJEP49kE9AQ=; b=WnPyCDQeKn42ReZpp7cZ76nBe2EJ19KxkTrIhxpkAoP2C4VGh4r8Fc1vVoYVOEA8MR shkT6WaJYe+FTbv6o20mfIrB+4k7MiuwktwJGEQYlve9GTlV+i+COG2k5w0RmKw9XYXG v1y+mnwTJ/xJJM+g9P+KHUmYl9zGTlbguJeEOkQwtzoIn0E9I29SxhuQuwYwleTmCFbO ohCD+PsRSzXGu2U3VBYU0VvfR7EV6SApM+sdr5BeuEagdOrUH/AiwczvTVtRIWY8CbZy /37dfk+0CiMXaKKF5Vg2TkVb6FfevZOyAeSNbLdiokIDNFw5lIz9YBdrhhixNjD/k1xA W5vg== X-Forwarded-Encrypted: i=1; AJvYcCWVI1eZejjgLg4/ZOP3S1JMXjAykXzQO0gWLGaAgq85jMrLW8EGYcY6Wl7GwojLypBq9/dCvcPqxJ7gvqI=@vger.kernel.org X-Gm-Message-State: AOJu0YxgYJMjz+EuPjqsCuh7ok0ciuDMIGQKfG54ThYAP73zXzuDeEKH EaV4C0fGcMgti65ty8IBK9WiA0y6rb4JmhJ9UNz8nw0c0th2gEDF2j3/Vg4qhNAXm8o= X-Gm-Gg: AY/fxX4LbwnL4ScqAnE+ICgmhuuEB3Rl7X6C1850TtVdQVMnhgy/FzZ57AjaRVdtyOM bkYmhfZmfWX9KVYS/hZb4DtJT4rjsaUey8XVwNSWtJy3mK+SOaKt5QI9KvEfY/25TN5LtAf1ghp HfQK0w9VLMQ99LeTzXeixdveh/Iaa+ZBY2onfm6Uszs4tP23frDePHEZfsuEIHPWTZC44NZ3oR0 j9TL1Zx/fazwywNCOQ669zr9grBDDodW93zEh0vqHvjdUnB4keOcCjc0tQxfKGIbh1unfhNVuHS QgTqipOO3/PUp59HEFF+z7QBar5XMwTghWGcWfwfuKv4VDGnRZ14euPIPRA6otPgl5XHzZBrclc Az5h41aOlCpYD6YyStvub5KOrrhrlXsgT8FPfT+BbAPKo1HlnWBNOTq3KlVyuxYXn0WoyniaSeR 8714W72hicApyMp7Gm5eSW/yFeqpOECKEJdaQ= X-Received: by 2002:a05:600c:1f12:b0:47e:e9c9:23bc with SMTP id 5b1f17b1804b1-4801e34ce8emr40733615e9.30.1768578927236; Fri, 16 Jan 2026 07:55:27 -0800 (PST) Received: from localhost (109-81-19-111.rct.o2.cz. [109.81.19.111]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801fdefed9sm19855285e9.3.2026.01.16.07.55.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 07:55:26 -0800 (PST) Date: Fri, 16 Jan 2026 16:55:25 +0100 From: Michal Hocko To: Mathieu Desnoyers Cc: Andrew Morton , linux-kernel@vger.kernel.org, "Paul E. McKenney" , Steven Rostedt , Masami Hiramatsu , Dennis Zhou , Tejun Heo , Christoph Lameter , Martin Liu , David Rientjes , christian.koenig@amd.com, Shakeel Butt , SeongJae Park , Johannes Weiner , Sweet Tea Dorminy , Lorenzo Stoakes , "Liam R . Howlett" , Mike Rapoport , Suren Baghdasaryan , Vlastimil Babka , Christian Brauner , Wei Yang , David Hildenbrand , Miaohe Lin , Al Viro , linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, Yu Zhao , Roman Gushchin , Mateusz Guzik , Matthew Wilcox , Baolin Wang , Aboorva Devarajan Subject: Re: [PATCH v16 3/3] mm: Reduce latency of OOM killer task selection with 2-pass algorithm Message-ID: References: <20260114145915.49926-1-mathieu.desnoyers@efficios.com> <20260114145915.49926-4-mathieu.desnoyers@efficios.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed 14-01-26 14:36:44, Mathieu Desnoyers wrote: > On 2026-01-14 12:06, Michal Hocko wrote: > > On Wed 14-01-26 09:59:15, Mathieu Desnoyers wrote: [...] Thanks to those clarifications > > My overall impression is that the implementation is really involved and > > at this moment I do not really see a big benefit of all the complexity. > > Note that we can get the proc ABI RSS accuracy improvements with the > previous 2 patches without this 2-pass algo. Do you see more value in > the RSS accuracy improvements than in the oom killer latency reduction ? Yes, TBH I do not see oom latency as a big problem. As already mention this is a slow path and we are not talking about a huge latency anyway. proc numbers are much more sensitive to latency as they are regularly read by user space tools and accuracy for those matters as well (being off by 100s MB or GBs is simply making those numbers completely bogus). > > It would help to explicitly mention what is the the overall imprecision > > of the oom victim selection with the new data structure (maybe this is > > good enough[*]). What if we go with exact precision with the new data > > structure comparing to the original pcp counters. > > Do you mean comparing using approximate sums with the new data > structure (which has a bounded accuracy of O(nr_cpus*log(nr_cpus))) > compared to the old data structure which had an inaccuracy of > O(nr_cpus^2) ? So if the inaccuracy provided by the new data structure > is good enough for OOM task selection, we could go from precise sum > back to an approximation and just use that with the new data > structure. Exactly! -- Michal Hocko SUSE Labs