Message-ID: <D7FF3455CE14824B+a3218eef-f2b6-4a9b-8daf-1d54c533da50@uniontech.com>
Date: Wed, 25 Dec 2024 23:42:29 +0800
From: WangYuli <wangyuli@...ontech.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Kent Overstreet <kent.overstreet@...ux.dev>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 yushengjin@...ontech.com, zhangdandan@...ontech.com,
 guanwentao@...ontech.com, zhanjun@...ontech.com, oliver.sang@...el.com,
 ebiederm@...ssion.com, colin.king@...onical.com, josh@...htriplett.org,
 penberg@...helsinki.fi, manfred@...orfullife.com, mingo@...e.hu,
 jes@....com, hch@....de, aia21@...tab.net, arjan@...radead.org,
 jgarzik@...ox.com, neukum@...hschaft.cup.uni-muenchen.de,
 oliver@...kum.name, dada1@...mosbay.com, axboe@...nel.dk, axboe@...e.de,
 nickpiggin@...oo.com.au, dhowells@...hat.com, nathans@....com,
 rolandd@...co.com, tytso@....edu, bunk@...sta.de, pbadari@...ibm.com,
 ak@...ux.intel.com, ak@...e.de, davem@...emloft.net, jsipek@...sunysb.edu,
 jens.axboe@...cle.com, ramsdell@...re.org, hch@...radead.org,
 torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
 randy.dunlap@...cle.com, efault@....de, rdunlap@...radead.org,
 haveblue@...ibm.com, drepper@...hat.com, dm.n9107@...il.com,
 jblunck@...e.de, davidel@...ilserver.org, mtk.manpages@...glemail.com,
 linux-arch@...r.kernel.org, vda.linux@...glemail.com, jmorris@...ei.org,
 serue@...ibm.com, hca@...ux.ibm.com, rth@...ddle.net, lethal@...ux-sh.org,
 tony.luck@...el.com, heiko.carstens@...ibm.com, oleg@...hat.com,
 andi@...stfloor.org, corbet@....net, crquan@...il.com, mszeredi@...e.cz,
 miklos@...redi.hu, peterz@...radead.org, a.p.zijlstra@...llo.nl,
 earl_chew@...lent.com, npiggin@...il.com, npiggin@...e.de, julia@...u.dk,
 jaxboe@...ionio.com, nikai@...ai.net, dchinner@...hat.com, davej@...hat.com,
 npiggin@...nel.dk, eric.dumazet@...il.com, tim.c.chen@...ux.intel.com,
 xemul@...allels.com, tj@...nel.org, serge.hallyn@...onical.com,
 gorcunov@...nvz.org, levinsasha928@...il.com, penberg@...nel.org,
 amwang@...hat.com, bcrl@...ck.org, muthu.lkml@...il.com, muthur@...il.com,
 mjt@....msk.ru, alan@...rguk.ukuu.org.uk, raven@...maw.net, thomas@...3r.de,
 will.deacon@....com, will@...nel.org, josef@...hat.com,
 anatol.pomozov@...il.com, koverstreet@...gle.com, zab@...hat.com,
 balbi@...com, gregkh@...uxfoundation.org, mfasheh@...e.com,
 jlbec@...lplan.org, rusty@...tcorp.com.au, asamymuthupa@...ron.com,
 smani@...ron.com, sbradshaw@...ron.com, jmoyer@...hat.com, sim@...tway.ca,
 ia@...udflare.com, dmonakhov@...nvz.org, ebiggers3@...il.com,
 socketpair@...il.com, penguin-kernel@...ove.sakura.ne.jp, w@....eu,
 kirill.shutemov@...ux.intel.com, mhocko@...e.com, vdavydov.dev@...il.com,
 vdavydov@...tuozzo.com, hannes@...xchg.org, mhocko@...nel.org,
 minchan@...nel.org, deepa.kernel@...il.com, arnd@...db.de, balbi@...nel.org,
 swhiteho@...hat.com, konishi.ryusuke@....ntt.co.jp, dsterba@...e.com,
 vegard.nossum@...cle.com, axboe@...com, pombredanne@...b.com,
 tglx@...utronix.de, joe.lawrence@...hat.com, mpatocka@...hat.com,
 mcgrof@...nel.org, keescook@...omium.org, linux@...inikbrodowski.net,
 jannh@...gle.com, shakeelb@...gle.com, guro@...com, willy@...radead.org,
 khlebnikov@...dex-team.ru, kirr@...edi.com, stern@...land.harvard.edu,
 elver@...gle.com, parri.andrea@...il.com, paulmck@...nel.org,
 rasibley@...hat.com, jstancek@...hat.com, avagin@...il.com, cai@...hat.com,
 josef@...icpanda.com, hare@...e.de, colyli@...e.de,
 johannes@...solutions.net, sspatil@...roid.com, alex_y_xu@...oo.ca,
 mgorman@...hsingularity.net, gor@...ux.ibm.com, jhubbard@...dia.com,
 crope@....fi, yzaikin@...gle.com, bfields@...ldses.org, jlayton@...nel.org,
 kernel@...force.de, steve@....org, nixiaoming@...wei.com,
 0x7f454c46@...il.com, kuniyu@...zon.co.jp, alexander.h.duyck@...el.com,
 kuni1840@...il.com, soheil@...gle.com, sridhar.samudrala@...el.com,
 Vincenzo.Frascino@....com, chuck.lever@...cle.com, Kevin.Brodsky@....com,
 Szabolcs.Nagy@....com, David.Laight@...lab.com, Mark.Rutland@....com,
 linux-morello@...lists.linaro.org, Luca.Vizzarro@....com,
 max.kellermann@...os.com, adobriyan@...il.com, lukas@...auer.dev,
 j.granados@...sung.com, djwong@...nel.org, kent.overstreet@...ux.dev,
 linux@...ssschuh.net, kstewart@...icios.com
Subject: Re: [RESEND PATCH] fs/pipe: Introduce a check to skip sleeping
 processes during pipe read/write

On 2024/12/25 21:30, Andy Shevchenko wrote:

> Don't you think the Cc list is a bit overloaded?

Hi,

I apologize for any inconvenience this may cause.

I understand that under normal circumstances, one would simply pass the 
modified code path as an argument to the kernel's 
scripts/get_maintainer.pl script to determine the appropriate recipients.

However, given the vast and complex nature of the Linux kernel 
community, with tens of thousands of developers worldwide, and 
considering the varying "customs" of different subsystems, as well as 
time zone differences and individual work habits, it's not uncommon for 
patches to be sent to mailing lists and subsequently ignored or left 
pending.

This patch, for example, has been submitted multiple times without 
receiving any response, unfortunately.

My intention is simply to seek your review, and that of other technical 
experts like yourself, but I cannot be certain, prior to your response, 
which specific experts on which lists would be willing to provide feedback.

I would appreciate any other suggestions you may have.

>> UnixBench Pipe benchmark results on Zhaoxin KX-U6780A processor:
>>
>> With the option disabled: Single-core: 841.8, Multi-core (8): 4621.6
>> With the option enabled:  Single-core: 877.8, Multi-core (8): 4854.7
>>
>> Single-core performance improved by 4.1%, multi-core performance
>> improved by 4.8%.
> ...

As you know, the kernel is extremely sensitive to performance.

Even a 1% performance improvement can lead to significant efficiency 
gains and reduced carbon emissions in production environments, as long 
as there is sufficient testing and theoretical analysis to prove that 
the improvement is real and not due to measurement error or jitter.

>> +config PIPE_SKIP_SLEEPER
>> +	bool "Skip sleeping processes during pipe read/write"
>> +	default n
> 'n' is the default 'default', no need to have this line.
OK, I'll drop it. Thanks.
>
>> +	help
>> +	  This option introduces a check whether the sleep queue will
>> +	  be awakened during pipe read/write.
>> +
>> +	  It often leads to a performance improvement. However, in
>> +	  low-load or single-task scenarios, it may introduce minor
>> +	  performance overhead.
>> +	  If unsure, say N.
> Illogical, it's already N as you stated by putting a redundant line, but after
> removing that line it will make sense.
>
> ...
As noted, I'll remove "default n" as it serves no purpose.
>
>> +static inline bool
> Have you build this with Clang and `make W=1 ...`?

Hmm...I've noticed a discrepancy in kernel compilation results with and 
without "make W=1".

When I use x86_64_defconfig and clang-19.1.1 (Ubuntu 24.10) and run 
"make", there are no warnings.

However, when I run "make W=1", the kernel generates a massive number of 
errors, causing the compilation to fail prematurely.

e.g.

In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from ./include/linux/suspend.h:5:
In file included from ./include/linux/swap.h:9:
In file included from ./include/linux/memcontrol.h:21:
In file included from ./include/linux/mm.h:2224:
./include/linux/vmstat.h:504:43: error: arithmetic between different 
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') 
[-Werror,-Wenum-enum-conversion]
   504 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
       |                            ~~~~~~~~~~~~~~~~~~~~~ ^
   505 |                            item];
       |                            ~~~~
./include/linux/vmstat.h:511:43: error: arithmetic between different 
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') 
[-Werror,-Wenum-enum-conversion]
   511 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
       |                            ~~~~~~~~~~~~~~~~~~~~~ ^
   512 |                            NR_VM_NUMA_EVENT_ITEMS +
       |                            ~~~~~~~~~~~~~~~~~~~~~~
./include/linux/vmstat.h:524:43: error: arithmetic between different 
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') 
[-Werror,-Wenum-enum-conversion]
   524 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
       |                            ~~~~~~~~~~~~~~~~~~~~~ ^
   525 |                            NR_VM_NUMA_EVENT_ITEMS +
       |                            ~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.

And I've observed similar behavior with gcc-14.2.0.

While I'm keen on addressing as many potential compile errors and 
warnings in the kernel as possible, it seems like a long-term endeavor.

Regarding this specific code, I'd appreciate your insights on how to 
improve it.

>
>> +pipe_check_wq_has_sleeper(struct wait_queue_head *wq_head)
>> +{
>> +	if (IS_ENABLED(CONFIG_PIPE_SKIP_SLEEPER))
>> +		return wq_has_sleeper(wq_head);
>> +	else
> Redundant.
>
>> +		return true;
> 	if (!foo)
> 		return true;
>
> 	return bar(...);
>
>> +}

Yes. I'll rework the code structure here. Thanks.

Thanks,
-- 
WangYuli

Download attachment "OpenPGP_0xC5DA1F3046F40BEE.asc" of type "application/pgp-keys" (633 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

Powered by blists - more mailing lists