From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 010A0C3DA6E for ; Thu, 4 Jan 2024 00:46:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51F746B02F0; Wed, 3 Jan 2024 19:46:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CF416B02F1; Wed, 3 Jan 2024 19:46:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 398786B02F2; Wed, 3 Jan 2024 19:46:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 251E16B02F0 for ; Wed, 3 Jan 2024 19:46:55 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D271C14026E for ; Thu, 4 Jan 2024 00:46:54 +0000 (UTC) X-FDA: 81639788748.22.8E0BEBE Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf15.hostedemail.com (Postfix) with ESMTP id 61CF8A0009 for ; Thu, 4 Jan 2024 00:46:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="km okchb"; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf15.hostedemail.com: domain of quic_aiquny@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_aiquny@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704329212; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1u0u+cekK6SHjywKHnBLUlogJbeRDzmxVO7K7k6K7N4=; b=lXZ2XzQGOWWRo3BOOoVT9/9JJLyRnljT3uV6WSZvVu/1fu4UdaVHhWto3CqcL6K1i7BwjE QQk7zvhBLexrtlaqGplhpp5Y/DqL5ul279kkKiwJWlhc8T9vsefi7dpvMbg+GdcUwi7mB8 Xe51BfDgiuTXJNfpwGiOint+qxG+oI8= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="km okchb"; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf15.hostedemail.com: domain of quic_aiquny@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_aiquny@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704329212; a=rsa-sha256; cv=none; b=GlPFPbRK5K5w7CpTZcyTDInrVhplihqkP65HpToq1/FN6ECDzVQSyKd3zPN6PRUQMau5kC 48hhN9me14vMScBU07u6+VQgwp/Tv+7w7dyuhLwuwISMUEFH06Oz8PdgHvuMQp0lwDlgh/ GY7MG5elpTu2VJ+1LSu4iKyBX01LO1I= Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 403NxDD4010114; Thu, 4 Jan 2024 00:46:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= qcppdkim1; bh=1u0u+cekK6SHjywKHnBLUlogJbeRDzmxVO7K7k6K7N4=; b=km okchbyqfOBzDREYspDvaZ3JlCItQPzkFSoeNdtlnUuT/a9T/n6gnvV2HuKhQoSDK V4aBkI3ODTJXVFR+ijSwsMwoMk+PFw16fHDAYCLF4K/EyCJe7oN81A+F64zZwWix U9yVZYRMI4Y/B810WRiNQ2f18WqNVwt63yB7658cgpc/t5lMvFVYsxBViUvbcIjC UvzXci4c0UJtyWMYXbqyPkHeN5Xuj0yzKZWn3hChqVzf7BakTKcC6+YEHrZlVG/4 Y73ix0pEIOX2BX/X4mPjW4zFQStH1UDPF6QuF9NmuV5Jib5dE4MffklNko/npKAj ywb4iC/KdrEyk2TmOsVw== Received: from nasanppmta05.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3vd3mb24nf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2024 00:46:42 +0000 (GMT) Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 4040kf2d016654 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Jan 2024 00:46:41 GMT Received: from [10.239.132.150] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Wed, 3 Jan 2024 16:46:33 -0800 Message-ID: <02e09c99-3431-4ba1-86bb-c4c68ebdc6b0@quicinc.com> Date: Thu, 4 Jan 2024 08:46:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kernel: Introduce a write lock/unlock wrapper for tasklist_lock Content-Language: en-US To: Matthew Wilcox CC: "Eric W. Biederman" , Hillf Danton , , , , , , , , , , , , , , , , , References: <20231213101745.4526-1-quic_aiquny@quicinc.com> <87o7eu7ybq.fsf@email.froward.int.ebiederm.org> <99c44790-5f1b-4535-9858-c5e9c752159c@quicinc.com> From: "Aiqun Yu (Maria)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: mpBZUrhu1N_Po1rEL0id7yrHQrooFGeq X-Proofpoint-ORIG-GUID: mpBZUrhu1N_Po1rEL0id7yrHQrooFGeq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-09_02,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 phishscore=0 spamscore=0 mlxlogscore=707 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401040002 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 61CF8A0009 X-Stat-Signature: oxnshg86rkx6y7iuboiak6wxtxwjf93d X-Rspam-User: X-HE-Tag: 1704329212-635301 X-HE-Meta: U2FsdGVkX1+JvocL2AzhlgSV0F7DanmoqRldGBEfLNOl7vEL12nwGqTy6ejDuFOCKIpCDtLF8UsunEyzieYgKl26V9KsbFfw/sJQ9biGw9QJP65pL6mdgDOKMxa4eLc0lhq5MfMaK7+KdN1uVPvpjckNYuv92BUbEghhA+DNVOE7InLPOdmbPTdpwYbmEHMMijlPg+H30wYLuz/YMdwYOhM1qLLzkUyo7cBtV4YmTgILDzCctcUAUGgVbOEndRzgwGgRx0+hoNJAaqX9dLMhfzpJQFfZp2Pbvr+l+At2wWPom56VqSffFNA6qUuoAgo6/ENvHOG2I0Un7DB7O/i7sS/9yhLci3/8PGPawAeMBcEpa8xtTZaSs6tYJhQDVz1v1vsZucVksuD4Sdwlp7W/vxvjG6TugGfR61c6nLRtRCl3zzRsZUwuJziuThYQOs5o49PPHVovI0vawj6U1XDY3uIC2OQ61UQ+A8+VDWdplwQ0d3XQBPnIOfd8/4Jw/2GUbVOk7DG9YTXCBoVPC3wK2qHzo20aG3k1yYJ8EvuIQcetG7aFJxmgEN7fzMnTWgDjrSlyrYfM4dxQD1Xrj2q9ERMHu+/6zlFMDQ54QMRp3NCb51F2gHjotgeiOe4RaJo/PwIVGDRz9ZPG2WoGI4ul8WaaFyx6b3FrWh9KeTFhC48tOBG7F6xTzcMJp8W5mo+mx+U/loXFAhBtscu3vfB7QeiKGTwdJEKGLUnc7ZnD4fZ3GoCsybAmPxIq0uU1gXNrPzB4C+JXzjqIfZ0ntLnIF60aTU4Ed0fPfSvhEWSpYu9UpTZpzfTY8ZgA/rv/xYrFt/ZR6/QJXYaasNLXSccpe7wcyU//nPu/mRuru+w2YnhqEQoErbtovOBTqFwOHneRjdD3CD5Bxnr1ccwOrnlKHs/5pxDl2zcZE28RwImpZZA/3QvGeR9SI++JZWh2xmaOQ9mkuEVC+wWATd8VzMa MFmj7Cto l6f1Ic8YWCh4Af3IlDnDFyyQe9emXnl4SvDHLnBGvu6nzv5UdQQ+O8XWoPVKG+ljCuq0JazBKHfQ2HuufwYUPTMqE52ZN7o36iQ8rMa1VfTFfPnCoJ0hv32bJxFxh3u1Ju/TQj7+ZEcuAiZCZWggc45xDI/8MD+Ud/nnxkER0pzwHnqmdlb5FFWvSqDzCVYh4zsQt6cmHChyUhorj/GbTELKYIKC867wcS5E/7JzspJxMTU7aE1cEi/PESHETL0+J+vHz4Y1zvn8aRRuoyvXwj+QUFnOjD952evM86GJPR6YNvEzSaMoBhO2GwniBPE5WLiQcxBKAOaREvJI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 1/4/2024 2:18 AM, Matthew Wilcox wrote: > On Wed, Jan 03, 2024 at 10:58:33AM +0800, Aiqun Yu (Maria) wrote: >> On 1/2/2024 5:14 PM, Matthew Wilcox wrote: >>>>> -void __lockfunc queued_write_lock_slowpath(struct qrwlock *lock) >>>>> +void __lockfunc queued_write_lock_slowpath(struct qrwlock *lock, bool irq) >>>>> { >>>>> int cnts; >>>>> @@ -82,7 +83,11 @@ void __lockfunc queued_write_lock_slowpath(struct qrwlock *lock) >>>> Also a new state showed up after the current design: >>>> 1. locked flag with _QW_WAITING, while irq enabled. >>>> 2. And this state will be only in interrupt context. >>>> 3. lock->wait_lock is hold by the write waiter. >>>> So per my understanding, a different behavior also needed to be done in >>>> queued_write_lock_slowpath: >>>> when (unlikely(in_interrupt())) , get the lock directly. >>> >>> I don't think so. Remember that write_lock_irq() can only be called in >>> process context, and when interrupts are enabled. >> In current kernel drivers, I can see same lock called with write_lock_irq >> and write_lock_irqsave in different drivers. >> >> And this is the scenario I am talking about: >> 1. cpu0 have task run and called write_lock_irq.(Not in interrupt context) >> 2. cpu0 hold the lock->wait_lock and re-enabled the interrupt. > > Oh, I missed that it was holding the wait_lock. Yes, we also need to > release the wait_lock before spinning with interrupts disabled. > >> I was thinking to support both write_lock_irq and write_lock_irqsave with >> interrupt enabled together in queued_write_lock_slowpath. >> >> That's why I am suggesting in write_lock_irqsave when (in_interrupt()), >> instead spin for the lock->wait_lock, spin to get the lock->cnts directly. > > Mmm, but the interrupt could come in on a different CPU and that would > lead to it stealing the wait_lock from the CPU which is merely waiting > for the readers to go away. That's right. The fairness(or queue mechanism) wouldn't be ensured (only in interrupt context) if we have the special design when (in_interrupt()) spin to get the lock->cnts directly. When in interrupt context, the later write_lock_irqsave may get the lock earlier than the write_lock_irq() which is not in interrupt context. This is a side effect of the design, while similar unfairness design in read lock as well. I think it is reasonable to have in_interrupt() waiters get lock earlier from the whole system's performance of view. > -- Thx and BRs, Aiqun(Maria) Yu