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 BCD8AC3DA78 for ; Tue, 17 Jan 2023 21:00:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C99B66B0073; Tue, 17 Jan 2023 16:00:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C49416B0074; Tue, 17 Jan 2023 16:00:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE9996B0075; Tue, 17 Jan 2023 16:00:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9AA2B6B0073 for ; Tue, 17 Jan 2023 16:00:34 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 66859160B8A for ; Tue, 17 Jan 2023 21:00:34 +0000 (UTC) X-FDA: 80365509588.24.C372874 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf13.hostedemail.com (Postfix) with ESMTP id 949FD2001E for ; Tue, 17 Jan 2023 21:00:31 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="g/lmjevr"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673989231; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YHXAUt3ny3FCa4wu6g+W377gbUsNdU3WemYAKDbc46U=; b=jyqX5U5rT0lnPqZ+VLTPzVkJ5DkT8vb2Q6LumzYksdBPDQ7h7Nqo7J0k9ccB26E2YOUMrx IUyArnulUBHGw+9WUaE9lNMIXiZ9d78hRWrw6gmxwtpr+nA5z/R4TmAdSSCHhzkQfdCTZ9 v0MFCS4L9M4lAW6vfvRG8Wfg2ohC1VI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="g/lmjevr"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673989231; a=rsa-sha256; cv=none; b=a6rddSMOgDGAN/Ecl3SMlv6On2PijcF9rdN/84ZJyI//zap1lwG3nSgXW6dKSXHvcN+3K3 IyAsI8ghKdu95suDvzJK7DqBBwjMsBTovqCV8nvRQekaO4mNbnzblvTFgvxeXE3ubVUUi/ r17syxFkmoKnutAQfizJg+KUzVjstOA= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-4d13cb4bbffso320265427b3.3 for ; Tue, 17 Jan 2023 13:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YHXAUt3ny3FCa4wu6g+W377gbUsNdU3WemYAKDbc46U=; b=g/lmjevrSe6/UrgH/yDr3jnG/kI4TrUFxc0eorY+CpDT2ykEH+lJRFAz/cWBd/zEdj MVdr/Ofoa6aR32CWHTpBkD8bDur2CQiRIheG7w7pM2NI6BvMQxXWQsrg5n0GwUhoL08J LdPT7k+/1CqROg1uiCmQdkoqciMYhUqAlsZBX28L2uX9bktKWGFWNUgc85DPZdW+WP11 Dkf6Qke8sjXQDbRvg/nVqX5qUNT+3VmFFIOLdIi6kJ+r7CbIcHOYMmbdHH3XgDg1gWBk ZM2hyaluuxbAIhpC67CkTkctrYeIFXRpdPjxKqPk4hdSGNqOxe0hx+oxT7VE5OnllhSR 20iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YHXAUt3ny3FCa4wu6g+W377gbUsNdU3WemYAKDbc46U=; b=xCut7v+M2oBCj8m+PRJP3ZyHyAG6E0xU2QrSkMFL/RUBCJDDqmd17+TLl/VFTnEPIQ LouJ1NP17SZ9Kmtw/sMlcB9x8IyzEy6ZSXtU8dmid/YicbB76m/Uajz1SHk/pGMEYf7O WWV4AKpHk0JikE1zSJbJ+NvbaZPDH0kOApSJ0teK0d6c1haRby2qofjmb3xDMS+2zqGM dKVq3+Lfde1u/frLPhk2kwF2dPcVox/M/aXGmhYUafBd8sAZTcHWw1qvClOH8uH9TLho IHkEqwm+fVGS1N8Gl9eTeFagFwx1limYB4ISfe3oWJdLdtjlwJoPOMSFIc7ULqBVqDAJ PVsw== X-Gm-Message-State: AFqh2kq5BpfzpG8Yk5qeX1Y5PLBSMPXKOhRrhyvdYLby4PZgcgmolA3p mow0Uf0SnCXR+bikizZvdqzvX6kntvuDmw4Q9CHrkQ== X-Google-Smtp-Source: AMrXdXtFBxrPIQwrnVbDPkv8eWbIPzbx4cIqKk4Gu4mHweZyTIBkyAUJF5bv5Cr4H2Zct//6eMLnSU/VFnEJZM2Oblg= X-Received: by 2002:a81:784c:0:b0:4e1:5013:6da1 with SMTP id t73-20020a81784c000000b004e150136da1mr666982ywc.218.1673989230419; Tue, 17 Jan 2023 13:00:30 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-42-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 17 Jan 2023 13:00:19 -0800 Message-ID: Subject: Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock To: Michal Hocko Cc: Matthew Wilcox , Hyeonggon Yoo <42.hyeyoo@gmail.com>, akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 949FD2001E X-Stat-Signature: rsfr165m1ygad9fu8nxn5h4cnajtwrkn X-HE-Tag: 1673989231-727633 X-HE-Meta: U2FsdGVkX19KnT4rBo2PN5a6Vevqa5ld/L7lOyR2PGg+uSEABbfSdZwJgUOK5/KM93Sjx5LuNWffb4+uftqP+CNCZEJ3Apf/AX0lTjxJ0s4g6bb77Ki/YSOgd3mxcHKke7SbBYVPbF1jGSPUV4BDVGuVCfaWLGDJAEOweN92dhs7nu3xPbnsakejyaEFn7cErxFAYqaOvLyRnuW9vwV7XeR0J9StyOZdIM6Fwpt+YOXqpWtuCDmeY+lRpSd8m8fUdT6PNQz2LCBwl6IjINy5ghBKnJbrIxNL61x2frZvyqOouTbLv+VTT5xb7nrhXH/e8EnaaY6S5JFRV/1WEQJgfPwYbBkuYUgINSPc1uZxCBygBUiX+MAgTXazbOHU9ymwok3m0QqahMFn1PDSl6KjVkxoIXZdPv08+nBPHsZEuzn7uv+uXBUsEpwOwaDm9IQxnfwwJOkfSTF/x+Wh7C6MyRnLaVJuVaQB0+x/k5CpByW5OZZjexuOPJKljLwsKaTjlM1tJFCSsVakNRzYENNHXfqZUYqK+pIY+LCfp+7VCSfkbnZdwdTaJg59HutfH1WpJ0+bDe3QY1qeRSwFB3D0dmvfTD9SaT2pojOqoKsUtkHQj4fzrLtg7LiB3/ebW/iqcz5z8er6j21vvxgSr9Y+9EvxeKFFys+iPPfwF2n1FeyqNurTGA8zeA6osYHmmxXNK5DbEpwv6ERhRedVxCRcBbpjPJHxQaKHey6VDXNyDqwXS3bpE6/VZJaW5uJa2VUD+HCoFnlU3pgEUoScnD/VKP07TXDdzgOVunfGaCm+mPtGGWiC8qoWXd9TKlm3+5RBOqntUEiTuH1Rstr3uhrN0iLk3tkhlKVhfGzBczyAjLuhDEt2uaycOOIR5FaNuzjP1M11JgjfdQUQP2CX6LeLwLiFtjxIs0yjMtGo2YJp+DuucJxJror8Q7TD2uvxozwuRdRjkNSlv5281HWUc7L z7SjhRgv ar+630wicKJrbbgjgkwcam7eupIrHaNMiqyR9PcoRsEsnFbHYDNlT0TrlYAjgKMIy2BoXCuJL8jS02W/6Wl3PsocebNyVdF5FjR7PQoXyXQ5jTeq2nB13LFlJRkaNyAT1EIU8 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: On Tue, Jan 17, 2023 at 12:31 PM Michal Hocko wrote: > > On Tue 17-01-23 10:28:40, Suren Baghdasaryan wrote: > [...] > > > Then yes, that's a starvable lock. Preventing starvation on the mmap > > > sem was the original motivation for making rwsems non-starvable, so > > > changing that behaviour now seems like a bad idea. For efficiency, I'd > > > suggest that a waiting writer set the top bit of the counter. That way, > > > all new readers will back off without needing to check a second variable > > > and old readers will know that they *may* need to do the wakeup when > > > atomic_sub_return_release() is negative. > > > > > > (rwsem.c has a more complex bitfield, but I don't think we need to go > > > that far; the important point is that the waiting writer indicates its > > > presence in the count field so that readers can modify their behaviour) > > > > Got it. Ok, I think we can figure something out to check if there are > > waiting write-lockers and prevent new readers from taking the lock. > > Reinventing locking primitives is a ticket to weird bugs. I would stick > with the rwsem and deal with performance fallouts after it is clear that > the core idea is generally acceptable and based on actual real life > numbers. This whole thing is quite big enough that we do not have to go > through "is this new synchronization primitive correct and behaving > reasonably" exercise. Point taken. That's one of the reasons I kept this patch separate. I'll drop this last patch from the series for now. One correction though, this will not be a performance fallout but memory consumption fallout. > > -- > Michal Hocko > SUSE Labs