From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 3DC6E19049B for ; Sat, 28 Dec 2024 18:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735412046; cv=none; b=ao5Opkg97obDWlkRW8QB9aRIgOp8rz9gvoyfn7H/KzUCQKXvK5dEUFK5YSq5dlWbOGKE9an9SBBMWYRkmA87rAYoFaXRFzKQAcZGVo423u/flwsfMip9GwcUEzBTu3puEBwD1AiBWg3boo+h6LEcHdnyMXBks5L6toZQM8z7ubw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735412046; c=relaxed/simple; bh=Bx6utfrucYDjk/Ma5GOl5Si/kIydjJ8uP4TzaNJ9iyM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tx101TcaDRMoQOyxACeGLlI0mqIqtkAecgAcsiXMicXytjhhmspYetIDpfrWf+N89qHOMnp4CJdldjQ3wdYbKDKEKuHrOEcA+MPEgfkt0m2oaPGDaPW2OOvUFx8N/lPRq4phSGQ8GLQpSafi/jrFLqbDuUokpVhdcoqi7ACJqgc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=colorfullife.com; spf=pass smtp.mailfrom=colorfullife.com; dkim=pass (2048-bit key) header.d=colorfullife-com.20230601.gappssmtp.com header.i=@colorfullife-com.20230601.gappssmtp.com header.b=AanS2JaR; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=colorfullife.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=colorfullife.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=colorfullife-com.20230601.gappssmtp.com header.i=@colorfullife-com.20230601.gappssmtp.com header.b="AanS2JaR" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5d3e9f60bf4so13674600a12.3 for ; Sat, 28 Dec 2024 10:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorfullife-com.20230601.gappssmtp.com; s=20230601; t=1735412041; x=1736016841; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=o4S0sqcHm4frtmlnS19N4Dv/daVSf9ZB3S3iMVK90YA=; b=AanS2JaRm3ZBg0bthkVruOgF7oB0tEbyw/GnEbRvPrtBwpUsgNYkGWAOB9xsL5G4gj 1knbyzrNE+Sb/2wevC4y5B+B5YV5Ul8H9dh+FK91Pg2FSCYIQDGJA9bvtymMO8C6q6oH 6whXu+V2sHzXqMGpvFc7OgDLFCcetnWhYkQW8zrvvxFwWswWO/Htc17vsM8LH3FZqkUD IGkLe4n32FxltYA+nFhA7RKLYsGRf5VxjW70jbmAjw2YmTIXDfj/vwColdjZZdHkHCmJ 9fyXmqPnKw2EoiNVWeKiLD7kqP+mwg2Qkd0+Ztx0ei+aY042u+iUgRwnzoLTsBsfKHLI 6daw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735412041; x=1736016841; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o4S0sqcHm4frtmlnS19N4Dv/daVSf9ZB3S3iMVK90YA=; b=qT4AhveNTC6r9v6Hbt68r2BN9xFwNFO0wJ1HX9FeHsATWZOxOUGhMUbTkRCdUHxAQk IGE+gpH0i/qWdVevvrhl4siAFhjkf/E32EZ1mw5u5IFMEvmBMVMSjkkBOakNj7c3yHzT va6QirGYwrNgq9s+nJxiQ8aG3Kr2nRuV5XpPirCJnOcZsfH2wjRua09Ny0RNhev2Nr5+ Aa318+9UZFxSSfPxGPp2R+6zmpKHzgmlHI/U0FOg28FzzmX4LOx0TiHJLFODACwemE/+ gVSGYVQbJYIjS7Q7w/JQhBcjv9USxWM/MzUTUQT/mi0O8XMGKtoZ+xq6OkmtYciH0xOS /ryA== X-Forwarded-Encrypted: i=1; AJvYcCU7wrZieRMm/bX8xN9P8nUJAMu0WEU3Uc+yteBkPipdcQTt5fr8JaH/CjiVMQcuaKnS2f/GWNWL4wbd9xg=@vger.kernel.org X-Gm-Message-State: AOJu0YyLgyytpFA92DdesuDRMAQbzBwVpeD27rbVec7CPV41IpB7QCvf HJdzNuTYLPZl+eB05j/iWVsaHpldz/2OQrqiyhbONBO5dq5QzFrZGMBmrFlD32Yyqx2ONFjVQ+o = X-Gm-Gg: ASbGnct8+xDb9GMF4KCBcizETQNVxDFTIHiDSuhf1atKnmqCt6xM9W6bAal0NQ7cKb4 RYneiLt3pGqmGIfAP9cHsOIVQz9a2Vws5IePqI8K8t2uENTMA2A95kY6hxZge5HNcnJDtJ8L/bq aw59I3FjfNX6ebqr5NcXDp1eVa9hI5IhwLSgLiP+luLjJHSq58U5YsS+N+/hEGvPYsdOC94wY+o 7nsZJYbXRMqwO8f1AiYJQdrjp+IdSE+SzdRoPpmliCHhD/ZpXMu+Va6OdjQ66mtggtW7NvCnIQr teL246GZH8IaOKLXdGm2PZeq882JmCYZRwEw8ma4IScX9NagxEQvSgGMLg14aL9C6gVIMPRT1iI uyXRjkZ308Pv6yRgpWsc= X-Google-Smtp-Source: AGHT+IHf9YD1SHw2OUXu56V+97edXC8Qj5MiJsLvI2eK3TkO2X6HY7zrYkCW9+id3cNuOI8zDkgtdw== X-Received: by 2002:a05:6402:2813:b0:5d3:d7ae:a893 with SMTP id 4fb4d7f45d1cf-5d81de23133mr27217465a12.25.1735412040922; Sat, 28 Dec 2024 10:54:00 -0800 (PST) Received: from ?IPV6:2003:d9:974e:9900:6aac:89d9:5e45:a0e6? (p200300d9974e99006aac89d95e45a0e6.dip0.t-ipconnect.de. [2003:d9:974e:9900:6aac:89d9:5e45:a0e6]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80675a3d2sm12532440a12.16.2024.12.28.10.53.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Dec 2024 10:53:59 -0800 (PST) Message-ID: <8d56b9d7-bb92-4c6e-ba8b-da3ec238943b@colorfullife.com> Date: Sat, 28 Dec 2024 19:53:57 +0100 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: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping processes during pipe read/write To: Oleg Nesterov Cc: Linus Torvalds , WangYuli , linux-fsdevel , Linux Kernel Mailing List , Christian Brauner References: <75B06EE0B67747ED+20241225094202.597305-1-wangyuli@uniontech.com> <20241226201158.GB11118@redhat.com> <1df49d97-df0e-4471-9e40-a850b758d981@colorfullife.com> <20241228143248.GB5302@redhat.com> <20241228152229.GC5302@redhat.com> <20241228163231.GA19293@redhat.com> Content-Language: en-US From: Manfred Spraul In-Reply-To: <20241228163231.GA19293@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Oleg, On 12/28/24 5:32 PM, Oleg Nesterov wrote: > On 12/28, Oleg Nesterov wrote: >> If nothing else, consider >> >> int CONDITION; >> wait_queue_head_t WQ; >> >> void wake(void) >> { >> CONDITION = 1; >> wake_up(WQ); >> } >> >> void wait(void) >> { >> DEFINE_WAIT_FUNC(entry, woken_wake_function); >> >> add_wait_queue(WQ, entry); >> if (!CONDITION) >> wait_woken(entry, ...); >> remove_wait_queue(WQ, entry); >> } >> >> this code is correct even if LOAD(CONDITION) can leak into the critical >> section in add_wait_queue(), so CPU running wait() can actually do >> >> // add_wait_queue >> spin_lock(WQ->lock); >> LOAD(CONDITION); // false! >> list_add(entry, head); >> spin_unlock(WQ->lock); >> >> if (!false) // result of the LOAD above >> wait_woken(entry, ...); >> >> Now suppose that another CPU executes wake() between LOAD(CONDITION) >> and list_add(entry, head). With your patch wait() will miss the event. >> The same for __pollwait(), I think... >> >> No? > Even simpler, > > void wait(void) > { > DEFINE_WAIT(entry); > > __set_current_state(XXX); > add_wait_queue(WQ, entry); > > if (!CONDITION) > schedule(); > > remove_wait_queue(WQ, entry); > __set_current_state(TASK_RUNNING); > } > > This code is ugly but currently correct unless I am totally confused. It is a chance of the add_wait_queue() path, thus impact on all calls. With (busybox) "find /sys /proc | grep aaaabbbccc", I've seen 16385 wakeup calls with empty queue, and just 6 with an entry in the queue. But on other workloads, the ratio was more something like 75% empty/25%with entries. I.e.: We would have long discussions if the change only helps for some usecases, and might have negative impact on other use cases. And: Your proposal is in conflict with https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/kernel/fork.c?h=v2.6.0&id=e220fdf7a39b54a758f4102bdd9d0d5706aa32a7 But I do not see the issue, the worst possible scenario should be something like: // add_wait_queue spin_lock(WQ->lock); LOAD(CONDITION); // false! list_add(entry, head); STORE(current_state) spin_unlock(WQ->lock); --     Manfred