[From nobody Wed Jun 24 21:37:10 2026 Received: (at submit) by bugs.debian.org; 23 Jun 2026 11:30:29 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-106.6 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER, FVGT_m_MULTI_ODD,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 30; hammy, 150; neutral, 108; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <cjwatson@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:36256) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <cjwatson@debian.org>) id 1wbzKn-000UGg-0z for submit@bugs.debian.org; Tue, 23 Jun 2026 11:30:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=3GBFrhEx92RKTnZjfJgzou5ZrTpP+w8UXK9o+WDUAzQ=; b=sWM5vUM30s25g/aB+1qVaiWwx6 71S8BRQuUgk5bptHphyZ8bN4n5LlwqTKwLQVcdfqZj9L32vgHg6lp1zPU2xmFsGvgZdNuzarwe1Zp NAvaljz4pkVB+H68JSeEgw986rHFdxtrb6IuSY60g2I+seiAsAieZWqRBwOxDwLr48cZDef7vunND l7c9rNhWwDvmdVhUe4jzCWNC3wHM2AKNdCn2KnIi9u/ln6rLpn8DtaqNfh98s+R0BK2JUTdqbmPTm b4lHptPginutVxZ1y66MvmQWtfaO0MDE82bAHGzUgMCzwrgM3o+4Y2w7zrH55d1lpHfhLNpt9dNPJ QdfGhdEA==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <cjwatson@debian.org>) id 1wbzKk-001cOn-1z for submit@bugs.debian.org; Tue, 23 Jun 2026 11:30:27 +0000 Received: from [2001:8b0:abaa:7b7:fc64:a67a:839a:e692] (helo=camorr.rosewood.vpn.ucam.org) by riva.rosewood.vpn.ucam.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from <cjwatson@debian.org>) id 1wbzKi-0000000879u-2TOo for submit@bugs.debian.org; Tue, 23 Jun 2026 12:30:24 +0100 Date: Tue, 23 Jun 2026 12:30:23 +0100 From: Colin Watson <cjwatson@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: nginx: Cache line size on loong64 may be too small Message-ID: <ajpuT7hc9yn-_ino@camorr.rosewood.vpn.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Reportbug-Version: 13.2.0+nmu1 X-Debian-User: cjwatson Delivered-To: submit@bugs.debian.org Source: nginx Version: 1.30.1-4 Severity: normal X-Debbugs-Cc: debian-loongarch@lists.debian.org, debian-loongarch@lists.debian.org User: debian-loongarch@lists.debian.org Usertags: loong64 I noticed that debusine's autopkgtests are failing on loong64 (e.g. https://ci.debian.net/packages/d/debusine/testing/loong64/72375884/). On investigation, I found this in its test artifacts: Jun 22 10:47:53 ci-173-ef19176d nginx[8035]: 2026/06/22 10:47:53 [emerg] 8035#8035: could not build server_names_hash, you should increase server_names_hash_bucket_size: 32 Jun 22 10:47:53 ci-173-ef19176d nginx[8035]: nginx: configuration file /etc/nginx/nginx.conf test failed I suppose we could work around this in debusine, as suggested in https://nginx.org/en/docs/http/server_names.html#optimization. However, I think this message points to nginx being configured suboptimally on this architecture. The default value of server_names_hash_bucket_size is set to nginx's idea of the CPU cache line size. Looking at https://salsa.debian.org/nginx-team/nginx/-/blob/debian/latest/auto/os/conf, it seems that this is set based on matching the architecture name. No specific value is set for the case where $NGX_MACHINE is loongarch64, so it falls back to 32. I'm not an architecture expert, but looking at e.g. https://github.com/golang/go/blob/master/src/internal/cpu/cpu_loong64.go it seems as though 64 might be a better choice on this architecture. Could anyone on debian-loongarch@ confirm or contradict this? Thanks, -- Colin Watson (he/him) [cjwatson@debian.org] ]