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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 C50C7C4CEC9 for ; Tue, 17 Sep 2019 15:53:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8CBFD2171F for ; Tue, 17 Sep 2019 15:53:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568735634; bh=bJ5COqEeLHd/ciHcEBGYUbvHL8Trh8FWoZaM96iQ8ss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=VOkIAmGiRLuyOEI+vU4kECCnV068WjoXKbKzgDxdPs6n/ZNZoBQXlFN16wWTpfK7R 2fqgoXWX+bWXwh2zaozI8l8aYj0L2q72SrtPrkTZkhXDHqjHvC8tQVBOhEDo0N2b7W 2fy8VPS9MkZ4ga/zzYBoT9X078zDk1IB67r8nzJc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729834AbfIQPxx (ORCPT ); Tue, 17 Sep 2019 11:53:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:51442 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729780AbfIQPxx (ORCPT ); Tue, 17 Sep 2019 11:53:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 18177AEBB; Tue, 17 Sep 2019 15:38:31 +0000 (UTC) Date: Tue, 17 Sep 2019 17:38:30 +0200 From: Michal Hocko To: Heinrich Schuchardt Cc: Andrew Morton , LKML Subject: Re: threads-max observe limits Message-ID: <20190917153830.GE1872@dhcp22.suse.cz> References: <20190917100350.GB1872@dhcp22.suse.cz> <38349607-b09c-fa61-ccbb-20bee9f282a3@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38349607-b09c-fa61-ccbb-20bee9f282a3@gmx.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote: > > On 9/17/19 12:03 PM, Michal Hocko wrote: > > Hi, > > I have just stumbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max > > observe limits") and I am really wondering what is the motivation behind > > the patch. We've had a customer noticing the threads_max autoscaling > > differences btween 3.12 and 4.4 kernels and wanted to override the auto > > tuning from the userspace, just to find out that this is not possible. > > set_max_threads() sets the upper limit (max_threads_suggested) for > threads such that at a maximum 1/8th of the total memory can be occupied > by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB > system this results in 254313 threads. This is quite arbitrary, isn't it? What would happen if the limit was twice as large? > With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") > a user cannot set an arbitrarily high number for > /proc/sys/kernel/threads-max which could lead to a system stalling > because the thread headers occupy all the memory. This is still a decision of the admin to make. You can consume the memory by other means and that is why we have measures in place. E.g. memcg accounting. > When developing the patch I remarked that on a system where memory is > installed dynamically it might be a good idea to recalculate this limit. > If you have a system that boots with let's say 8 GiB and than > dynamically installs a few TiB of RAM this might make sense. But such a > dynamic update of thread_max_suggested was left out for the sake of > simplicity. > > Anyway if more than 100,000 threads are used on a system, I would wonder > if the software should not be changed to use thread-pools instead. You do not change the software to overcome artificial bounds based on guessing. So can we get back to the justification of the patch. What kind of real life problem does it solve and why is it ok to override an admin decision? If there is no strong justification then the patch should be reverted because from what I have heard it has been noticed and it has broken a certain deployment. I am not really clear about technical details yet but it seems that there are workloads that believe they need to touch this tuning and complain if that is not possible. -- Michal Hocko SUSE Labs