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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC2F3C38142 for ; Tue, 17 Jan 2023 23:16:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229529AbjAQXQB (ORCPT ); Tue, 17 Jan 2023 18:16:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbjAQXNp (ORCPT ); Tue, 17 Jan 2023 18:13:45 -0500 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4F0023D91 for ; Tue, 17 Jan 2023 13:00:31 -0800 (PST) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-4b6255ce5baso439909617b3.11 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=SEU+ArMJJvug2BMtAOs55RgwJBj5x3gSWT5+OKo0lqaYYqsYFE4+Qumfm/UgNfZjVM AIN7xsu+yz+8ShcLgiuxW5lQwQ400OweFKuW6+MSjXa9xQBQYbARz8ejsQG4d0PZ4/F5 kjhfPs9hhWAsDKCeS41RRBBv9U3vQUiQsTDQfn2c8xk+HC9rljKds1fLQW7Iqp/GkXhk IIPhKzonOK6PkeIgkzgeenVJmBXQ9Rux2ckgJzfNqkSYtY9QFMGP6S9ttcyFEn+pQGYl p9mS/EBPkiid51iVUzO6c79yoc2tWH9hOxW+WtEfLMRVqT5VnHVrd1RJecTHauFxBENg AGOA== X-Gm-Message-State: AFqh2krw0RYEEVR37bio6yRoDU2kodE7fnhUCU1bXvKxfn3mmJwpjoK8 eRYxM+lFZnc5XMGDmL2TkGyEnDI/Go7Fo2r40Shsbw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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