From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 8CCD622D785 for ; Tue, 30 Dec 2025 13:25:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767101155; cv=none; b=KeWdCoy4jYE+weUQvStO9wenm4Qh8NUjY2FlqYB9SPiTDPshLV6MKOjXDQURZUlwgzCsWjckY0ZMG3p5jD0m1RzME7ELyFu7Myn1p0BAfaW7N1NWM5+cNpWyC9qioUJkwD3AjGLIMyUulHgcVXHwgnEDxFm173ZtXGBcuGyBaug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767101155; c=relaxed/simple; bh=CB+l18UGuH3zqTcijvnmTJRxiAa4UGKlknwa652Tnrs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qqVTO8oa8lMs8covbkOKONJLIO/+kPW2gZGyHZDfxljfG0WuI5ya+s6gLW9Rnqc9OPyCZAF8vXaBhwzLHyy/LD8F5Hw8JNJ8HUt+awff/lyEctB5SZIJlFaNU0qEe64q1shrA3986ApQmNJbqBATKFJXGD0EeVrhFwGovURRAJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MM92fhck; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MM92fhck" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-29f2676bb21so134310845ad.0 for ; Tue, 30 Dec 2025 05:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767101153; x=1767705953; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=z+S/7yAzOfWY95UqOaUD23OvyPe0W7m0t5JIL18uHak=; b=MM92fhckkILXKlR4qwW4+LAkYjC/K9GnQZ5jsxzREe5hq7RR1DOnu09VWHHzOp6MUH s1CDAvTLo9DMwXWbopeEsy4wka4jRLwXh9v3RrmFDcM7ce3/H2gKhj8/7I9HDb97nfKL jwKbIhG/tz21kLeBTHEK464dmx/LczHd2UypzrzAyRFcfpnziL2P888lxv33nG89BJHq v0+nhQw+4HNF1FF45c0CsKwWtVvA2sDYy1BcBRNv1FwBdJR6S/kFpagWCy7TDhnGfLic iJqQu1G5KrXwYw8y1N7i/cQ6Fr6GAgQMS/tpxnHKsoNCTGkzFJo1B79Mltj+izF4lLW9 N4IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767101153; x=1767705953; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=z+S/7yAzOfWY95UqOaUD23OvyPe0W7m0t5JIL18uHak=; b=N1AeCyyIZCy1doqjwmlimiFmhPMJDkDnO5RnMeHyToIB1j6k+2NkNdVJOc9iHNxd1U k+OdyZ3pLzCxYuomOE6dk6Y/zT667MZsfDZvNZjej8TCnaymvuWrWHtd4bAfXR2UXKB6 N2H9RlIuL3x6Yjs6A+52kTyzW5jGmUh9sEVvUHSVSBGHDOvCLuKGO9Nw5Kp3Me6v5nFz UIOVP2tdggkNy935nQawZ6rlg74Bd6hUl17HAiWMvrshvH7I4dAspYrrqaRzJeAI652t iMLoQeOGeYmdlrPMR4tYwLu38Inpw6VZDxtQGHH3PqCINjAHAiPT23qz1936EWLsjyKY LPSw== X-Forwarded-Encrypted: i=1; AJvYcCVpInherzKHAa6yTX84Q73wSEVIZhnAYhSpBiT/+PVjUMEtc36PAB1vQPVDov843c1y2Y2WkVaEhDwG09o=@vger.kernel.org X-Gm-Message-State: AOJu0YwJ1cQv94Y2FPc9E2f4QYX6iVbqM/c8ClhdMfJAE3tAewu/euQK Vx/0Wol2+TUaPPcG0h2HmKLTzGSa2ZeTLYh0y23H5cGW27DXgRKePEld X-Gm-Gg: AY/fxX47DRGD1GPDAEKlvzqNshKhE8wCyL1tFXgjLiL7VcYTd+4NeibYKYp8wlYdY3B dkmkiJH8zPaB+RKi/YnOlN7taxc4tmA6PTFhb4j+/l4JSaB4/BvUVF+MQb3WMzSegg4RdQoPu9e lYWrRBFEw0cGBODlPRJW5dCOgGiUlXu50OMA8vQ253qDQL2/MLQstNh3OAiY1OFPNYWkVQ7z0oU I4Fjl6S6Bb68+P2PHUBVYLMTw0wXxKOqGrYejbNkWtQ6OsXQpiB3wd3j136e4ERI6QLJ/vlP3kI dFsYnHsodB1QPtLm5P0ne7Z4RVr2T6w0GeQ8qqOxIT2NREMCCyJmXzEp2Ock8/ZzmrXtrMkgf9W QVP95SYaT8Oj4nZupNJe7K8s6AbTY7CEpCDFC2ukzg+zxBQC6KrqiBiQo4g23V5cYjVKGgq50xi 3r20klNdgX0JQ42CeMlb3AAHaSmKlheJI6Ip+pkPM= X-Google-Smtp-Source: AGHT+IFXNm3C2mwrIpx1iDrEL4OT1TdN/7Fle+1ZWO16KKK6xi8KboIaQcFKaGeKRKJ+4h6ZQXZPpQ== X-Received: by 2002:a17:902:eccb:b0:2a0:8358:88f8 with SMTP id d9443c01a7336-2a2f232c841mr331731235ad.22.1767101152774; Tue, 30 Dec 2025 05:25:52 -0800 (PST) Received: from [192.168.0.22] ([175.119.5.143]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f3c66465sm305743675ad.15.2025.12.30.05.25.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Dec 2025 05:25:51 -0800 (PST) Message-ID: <2c1e9438-d7db-41ce-aad8-85cede2957d4@gmail.com> Date: Tue, 30 Dec 2025 22:25:48 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question: batching block allocation in f2fs DIO path Content-Language: ko To: Chao Yu , jaegeuk@kernel.org Cc: Jinyoung Choi , Jeuk Kim , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net References: From: Jeuk Kim In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/2025 6:27 PM, Chao Yu wrote: > Hi Jeuk, > > On 12/29/2025 2:33 PM, Jeuk Kim wrote: >> Hi F2FS maintainers, >> >> Sorry for the duplicate — I’m resending this because the previous >> message was sent in HTML format. >> >> I’ve been looking into the DIO allocation path in f2fs, specifically >> when a DIO write needs to allocate new blocks (e.g., hole-filling). >>  From f2fs_map_blocks() through __allocate_data_block() → >> f2fs_allocate_data_block(), it seems each block allocation is handled >> one-by-one, taking curseg_lock/curseg_mutex and the SIT sentry lock >> per block. >> >> I’m wondering whether batching allocations (a bounded batch, e.g., a >> small run within the current segment) could be feasible in the DIO >> path. My intuition is that with multiple threads doing DIO, reducing >> per-block lock contention and improving sequentiality could help >> throughput. > > I agree w/ you. > >> >> Questions: >> >> Is there a technical or correctness reason that makes batching for DIO >> infeasible (e.g., LFS/SSR/GC interactions, summary/SIT update >> ordering, etc.)? >> >> Or is this simply an optimization that hasn’t been implemented? > > I've implemented a prototype of multiple block allocation for any > potential > use cases: pinfile fallocation, direct IO and buffered IO. I can see > benefits > from my previous test. > > I plan to upstream all implementations, but I think I need more time > to clean > up the draft codes and check all corner cases. > > You can check the MBA implementation for pinfile use case in below > link, I > guess this version is close to upstream. > > https://github.com/chaseyu/f2fs-dev/commits/feature/inbatch_write > > Thanks, > >> >> If this seems acceptable, would you consider patches in this direction? >> >> If there are prior discussions or known issues on this, I’d >> appreciate pointers. >> >> Thanks for your time. >> >> Best regards, >> Jeuk Kim > Hi Chao, Thanks a lot for sharing this and the link. Good to hear you’ve seen benefits from the MBA prototype. I’ll look into the pinfile implementation and try testing it on my side. Thanks, Jeuk