From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id A6338B9C16 for ; Tue, 12 Dec 2023 10:21:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7E72F31890 for ; Tue, 12 Dec 2023 10:21:06 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 12 Dec 2023 10:21:05 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4E14545F8A; Tue, 12 Dec 2023 10:21:05 +0100 (CET) Message-ID: Date: Tue, 12 Dec 2023 10:21:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20231210144940.2031248-1-aderumier@odiso.com> <20231210144940.2031248-2-aderumier@odiso.com> <468db986-a957-4216-b4c7-ce9243f9f092@proxmox.com> <05582a7f6e3e17166fa9af2e757fc8fffd4d9e1d.camel@groupe-cyllene.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <05582a7f6e3e17166fa9af2e757fc8fffd4d9e1d.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.077 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH qemu-server 1/1] fix #4507 : increase qemu max openfiles limit X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2023 09:21:36 -0000 Am 11.12.23 um 17:29 schrieb DERUMIER, Alexandre: >>> So not sure if that's really nicer. This suggests QEMU should raise >>> the >>> limit itself. > > Yes, but it don't raise the limit :/ But it's really working with more > than 1024 file descriptor. > >From a quick look, I didn't find an option to pass along QEMU for this, so it would likely need to be implemented first/discussed with upstream. But thinking about it a bit, it feels wrong for each application to be responsible for raising the limit itself. Sure the application needs to avoid using select(), but IMHO such limits are better set from the outside. I think your approach is fine, can you please send a v2 with a Signed-off-by and my nits addressed? I mean, ideally select() would just change to allow getting rid of the low default limit, but the man page says it won't, so ¯\_(ツ)_/¯: > WARNING: select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024)—an unreasonably low limit for > many modern applications—and this limitation will not change. All modern applications should instead use poll(2) or epoll(7), > which do not suffer this limitation.