From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 7830D421880 for ; Tue, 26 May 2026 17:55:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779818137; cv=none; b=S+7EitGQi/pOrFAtii0YyYqTOaXeEhmo3R1K3W+pcOV5AaPFhV1oSq6ovbRs5zTAFjpwuAyk5tmyaSDrsAc3rvwvQbygRjr/UHID6i+uavVZTGCbmQCZz47R/p88rXPd1ND1UbYSWBgsp2jWFdwJtrPumLKjPfVUfrLenAsErNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779818137; c=relaxed/simple; bh=DGbGprOejO1JyZgVGWwttMJBI4w1MQ6AcyVoxjtIeJE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q0X4UZ8hEgnmE4JOql9xTkDnSPCFbooWto/n+I/eva1hjwOsv8YK3yJY6JUBAuV+WlmPfxXL4uTQOT4v0TMkSbFhUK3wi0f4HTRRwHHbSiyWAl0mHYVvTK+7Ad62ZlIb1/18wFEw8qM6fFhBdN7bb2oVxV5DBOf49dKnYVOfSzg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-4903974854dso46581485e9.3 for ; Tue, 26 May 2026 10:55:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779818135; x=1780422935; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=az8w1SBKxR0VeFE6GKHEec3/Op4ln2y/HZZ5hj4Zcl4=; b=cZxBuTW/3ofzDNan1OqEJH9ugl2Ow8PyS3mQ9Y/AwmEvgEtAoCFZb/i95srMGVF18y 5+ER9o4rtN85iRqGnRWIRG3BtIa0jjKCLN9nS8G7793o/kY7SgiCXX/8oqbsX+/8NCNp D4czDteTIvUSsEVWFoQYICZcKOaXQ6qgkkLd+3k07q0IEGMwIBIzWJoMQ517JnU/lCfk iEhYb5LcjYLMh/8z8NPiIMpG0zniQfjYdCvyGBXCLIgmRF4kEYmMGl/MV+wpvDHCtDhh iryP3QNLkR5+V9YxCmJCtkbFGL1cB0GOx7fJl/gYc4/cWu4K9oO3SXIuKt2yr4s3OGof nU2w== X-Forwarded-Encrypted: i=1; AFNElJ/fH+Yy9Ucm1umntnw8Mp6q2o4xPlNj8JZR7cclzlMh6wWRYz32CG/TZdHdrG/ZbKxKbjJ6mtSEOvi0LbI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzkx7V5NjgvI2588DbnP+2qYhORtaFhkqrB7P7AzepCmDk3GTBU FUCOJfcp5W3vyF1nuzoyWGmXNyY+JYiVRWTk/SVhayCFY94egTBguk0I X-Gm-Gg: Acq92OHw9QEatle9uBKR5QG8pBFdF3emO9oHJdYOkshbvkn0s8u2xdgoCsYTKyrc/n0 Rh4Bn5jkqSXWz324GutSI04zrxPb45R+Sy0sdovra9R0V39s8QQgHj9eW38aM7e5EuSh9ZbSK/k NPPnX9VbPHXaiUaYs15zhl4AZq4phpBErZ6i1SbyXYYzRcaWU3q7XLH+/8g/c1l30A0cnN9xqzR 52KabkQQuQ/d3UlVatsFoOAh4dzzn0oZ3zzNq1V6icGdxUeMAQ5AgeznNl1oq679dm0nGSY3Ub+ JqQfBZTMA03YlE7+haeSjMNE3WLJLMkJO3fkhiOUaB9lrFVKLGnOBSNO0kdR2Ar9KsEcJXWYfeZ 52wJ/0IvKShQzec2dezZWdmRbWZPsSnMC5GOpK4RWyEFKcQKLi4wKfHppd0+7fIo653gvHH/rD4 vcizmNMz8XRREuoBaouW3c/ycLYQ== X-Received: by 2002:a05:600c:8217:b0:490:51e9:deba with SMTP id 5b1f17b1804b1-49051e9e233mr248777025e9.27.1779818134620; Tue, 26 May 2026 10:55:34 -0700 (PDT) Received: from gmail.com ([62.197.47.167]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4907e7d0967sm1014105e9.11.2026.05.26.10.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 10:55:34 -0700 (PDT) Date: Tue, 26 May 2026 18:55:33 +0100 From: Breno Leitao To: Namhyung Kim Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v2] perf bench: add --write-size option to sched pipe Message-ID: References: <20260521-perf_bench_pipe-v2-1-720b6ff7f0fa@debian.org> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: hello Namhyung, On Mon, May 25, 2026 at 09:17:45PM +0000, Namhyung Kim wrote: > On Thu, May 21, 2026 at 09:15:37AM -0700, Breno Leitao wrote: > > + ret = write(td->pipe_write, td->buf, write_size); > > + BUG_ON(ret < 0 || (unsigned int)ret != write_size); > > ret = read_pipe(td); > > - BUG_ON(ret != sizeof(int)); > > + BUG_ON(ret < 0 || (unsigned int)ret != write_size); > > Is it possible to return smaller values than required due to signal or > something? I tested this on a VM with the patch applied, running the ping-pong with write_size from 4 B up to 1 MiB, including multi-process and single-CPU contention runs (millions of iterations). I observed zero short reads or short writes. Looking at fs/pipe.c, this matches the kernel behavior for this access pattern: the bench has a single writer per pipe and the pipe capacity is set to write_size, so the writer never has to sleep mid-write, and the kernel does a sync wake of the reader only after the full payload is queued. EINTR is also not reachable today because the bench installs no signal handlers and nothing in the call chain delivers signals to the workers At the same time, I understand the concern and If you'd still prefer defensive handling (short-return loop + EINTR retry) I can add it in v3 — happy to either way. Thanks for the review, --breno