Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Hui Tang <tanghui20@huawei.com>
Subject: [bug-report] possible performance problem in ret_to_user_from_irq
To:     Russell King <linux@armlinux.org.uk>
CC:     <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
        <tanghui20@huawei.com>
Message-ID: <7ecb8f3c-2aeb-a905-0d4a-aa768b9649b5@huawei.com>
Date:   Mon, 26 Dec 2022 16:45:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

hi folks.

I found a performance problem which is introduced by commit
32d59773da38 ("arm: add support for TIF_NOTIFY_SIGNAL").
After the commit,  any bit in the range of 0..15 will cause
do_work_pending() to be invoked. More frequent do_work_pending()
invoked possible result in worse performance.

Some of the tests I've done， as follows:
lmbench test			base		with patch
./lat_ctx -P 1 -s 0  2		7.3167		11.04
./lat_ctx -P 1 -s 16 2          8.0467		14.5367
./lat_ctx -P 1 -s 64 2		7.8667		11.43
./lat_ctx -P 1 -s 16 16		16.47		18.3667
./lat_pipe -P 1			28.1671		44.7904

libMicro-0.4.1 test		base		with patch
./cascade_cond -E -C 200\
  -L -S -W -N "c_cond_1" -I 100	286.3333	358

When I adjust test bit, the performance problem gone.
-	movs	r1, r1, lsl #16
+	ldr	r2, =#_TIF_WORK_MASK
+	tst	r1, r2

Does anyone have a good suggestion for this problem?
should just test _TIF_WORK_MASK, as before?