From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C67D8371867 for ; Tue, 3 Mar 2026 01:33:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772501616; cv=none; b=QPde6Vg9hHTpfE/Dr/H0O27bV52NohQ+Yoaxaf988dbWtA/ehFPq0dRt2NkfZFEioMIVTcEkOdkkZuRhQCHwzDys5QhAP5b4ZNg7x721ITR0wTLGANAnJXaMW6veuct2efheHot4KvVSY3cdrpyslGafLY7dR0WNF0aTCKqakRU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772501616; c=relaxed/simple; bh=1x/z4lsjvRVrm8u90IJ/ogmuf2BMAxXWCertaRUyDi4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rKiUg5pzu1a8KbN7mU35qvxlV8YrquL+0As30esJGfTDHYQzIXs6EV6HK7vXiAtCfdKN/z2+cuj2Bs/v3uEUVJqGpOQq3bPcUJAoasJkj+biiG1ReXmSimQ+d8VzjGmVGBKK41wQ2eHIRf6a8HGxNeMUuHB6BdwaPyWVkXVQpaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=T1b5uIjX; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="T1b5uIjX" Received: from macsyma.thunk.org (pool-173-48-102-84.bstnma.fios.verizon.net [173.48.102.84]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 6231XAkA029560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Mar 2026 20:33:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1772501592; bh=LjvMyfV6wGhEgTswJWDP+qMkqBgbdWSVw/aER82y5jk=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=T1b5uIjXQ9U1se7/MT8v5M89PAihrlaKLwADFXPiIdJUkTNIHlKZLANTt7xF4eMAd TieofBFVLNBalBIi+CXhZfP01cC0g6qN0bT9puMWwIHJKCYmViW0ggsU8DokadfB02 JOmw7YAnDTZoAcEy8PzLzqO2V+VZqEWjgmY0wbyjuoMf+Sf4uAN4CG56KugtyISYYQ Kf13KmJUUA0V0Ar1XOqTY+MYHzwvWc2l+ZxlLgDlgyHyiSXt9BN1YnY7nRCt6iqFNf eF82UoOZYXLLeAFKsNi8UAThkglYW9D2U10JVZYNaWR3zW5JtaRr+iSazPH/2pEzqP BXTPhrO5w1ZXw== Received: by macsyma.thunk.org (Postfix, from userid 15806) id CCB9B5AC5D2D; Mon, 2 Mar 2026 20:33:09 -0500 (EST) Date: Mon, 2 Mar 2026 20:33:09 -0500 From: "Theodore Tso" To: Mario Lohajner Cc: Andreas Dilger , libaokun1@huawei.com, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, yangerkun@huawei.com, libaokun9@gmail.com Subject: Re: [PATCH] ext4: rralloc - (former rotalloc) improved round-robin allocation policy Message-ID: <20260303013309.GB6520@macsyma-wired.lan> References: <20260225201520.220071-1-mario_lohajner.ref@rocketmail.com> <20260225201520.220071-1-mario_lohajner@rocketmail.com> <20260226024819.GA39209@macsyma-wired.lan> <04dfeda0-8c13-4233-b631-d8912d4fe6f0@rocketmail.com> <20260227011200.GA68551@macsyma-wired.lan> <2af6328d-5a72-476d-9768-9398a9417ea6@rocketmail.com> <20260227164319.GB93969@macsyma-wired.lan> 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 Mon, Mar 02, 2026 at 09:04:44PM +0100, Mario Lohajner wrote: > RRALLOC spreads allocation starting points across block groups to avoid > repeated concentration under parallel load. There are already other ways in which we spread allocations across block groups. You need to tell explain a specific workload where this actually makes a difference. Also note that in most use cases, files are written once, and read multiple times. So spreading blocks across different block groups is can often be actively harmful. > In high-concurrency testing, performance is consistently comparable to > or occasionally better than the regular allocator. No regressions have > been observed across tested configurations. No regressions, and only "occasionally better" not enough of a justifiation. What is your real life workload which is motivating your efforts? - Ted