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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F221C433EF for ; Wed, 29 Sep 2021 19:09:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC4AE61507 for ; Wed, 29 Sep 2021 19:09:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DC4AE61507 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 326D3940050; Wed, 29 Sep 2021 15:09:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D61D94003A; Wed, 29 Sep 2021 15:09:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EC4A940050; Wed, 29 Sep 2021 15:09:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id 1054B94003A for ; Wed, 29 Sep 2021 15:09:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BE9B426DE8 for ; Wed, 29 Sep 2021 19:09:09 +0000 (UTC) X-FDA: 78641548818.18.9F6DD14 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf18.hostedemail.com (Postfix) with ESMTP id 6EB4E400209A for ; Wed, 29 Sep 2021 19:09:09 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id om12-20020a17090b3a8c00b0019eff43daf5so2785853pjb.4 for ; Wed, 29 Sep 2021 12:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=w/o+qoDJAQwAytEoBvjDbZyVGk8n5KAazoJGtDSKuSU=; b=F2g2FIC4MsFVL+ygRSHhS0KmVTFf/CICrBZaZEGv6rxH4UZ3NO22XM88rsm2SNPc9r wcFvSlXOeRpc9jGcyhP6Svq5+mEx3mAb3YmhooncPG/UgVp1+oUSMMjNdBE3qdJ5tXRd nCiGof/+1zPcc0SPVaWZYwzcogmOMJaJpn5mHy1fmGdkW5PWjF3WuBqzoMvxDscLq8pY 3RKIZwzi59GHw5KOyJOgA6rMI5rqyCuIhnbdHzeAhn/sl/v/9FkehNaeFr8NQw0cEAwM 5RyRPBl8gJwekRtqFvlt4pCSXJ4t+skUhB69HGm8VJ/bVjfK8gy0dU2ujSEGSTTX7t79 hSFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=w/o+qoDJAQwAytEoBvjDbZyVGk8n5KAazoJGtDSKuSU=; b=ix9VvskcJNTHhsr9xStbZY4xLSaiuTGSpzp0XdPbYw+CJZ+gdoK/McHUl3Q88ReErh DeqxjJB8XNnjNIwOZiF1pqdQGEgETa6b8YUESoQiUnpxQm65onbBAXKobo/4Kvm+bpb1 6t8e8OSZM4U7mfvWoe6ttx60ipYGLtfSx91a3wSFsG0bXRVoc1W18yS5ZeUD0m1HdIE0 ZjcFC48dGdn3VgBQudcrNb6NqQew8WEJlE1A7yjujtznYZq8rizfRo8YgEAe3P1zCYma QAeWWunmeH1e3NAVMMRwQ/C24ww3MqqGI7Q/gbZK6U8ydpuAMRJHcMKnObFX5GAegfh2 xujQ== X-Gm-Message-State: AOAM533VDp1vezdFrz69GTiYTjTGCdvEjQYXPvaIf+NhmZw3G4Q0fj0e OmWyKQfJ8Vq9BokC9lBdSH4= X-Google-Smtp-Source: ABdhPJwrdCr4lA+bGInTn75XA7/k5WC+e4NU7tVR5mHCu1/5SES/1b9c+TnMBNrNoP9gYUoIDnoJHg== X-Received: by 2002:a17:90a:d3d6:: with SMTP id d22mr1648664pjw.242.1632942548233; Wed, 29 Sep 2021 12:09:08 -0700 (PDT) Received: from google.com ([2620:15c:211:201:b20:38b0:e128:5c19]) by smtp.gmail.com with ESMTPSA id q11sm533650pfn.91.2021.09.29.12.09.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 12:09:07 -0700 (PDT) Date: Wed, 29 Sep 2021 12:09:05 -0700 From: Minchan Kim To: Sebastian Andrzej Siewior Cc: Andrew Morton , linux-mm@kvack.org, Thomas Gleixner , Mike Galbraith , Mike Galbraith Subject: Re: [PATCH] mm/zsmalloc: Replace bit spinlock and get_cpu_var() usage. Message-ID: References: <20210923170121.1860133-1-bigeasy@linutronix.de> <20210928084419.mkfu62barwrsvflq@linutronix.de> <20210928154723.1b0577818143734653d9b129@linux-foundation.org> <20210929072359.zkzg57gf362tc76m@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210929072359.zkzg57gf362tc76m@linutronix.de> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 6EB4E400209A X-Stat-Signature: nqut9z7htq8drwmcdfyu6tx4m4prbq5q Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=F2g2FIC4; spf=pass (imf18.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-HE-Tag: 1632942549-433418 Content-Transfer-Encoding: quoted-printable 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 Wed, Sep 29, 2021 at 09:23:59AM +0200, Sebastian Andrzej Siewior wrote= : > On 2021-09-28 15:47:23 [-0700], Andrew Morton wrote: > > Rather nasty with all the ifdefs and two different locking approaches > > to be tested. What would be the impact of simply switching to the ne= w > > scheme for all configs? >=20 > The current scheme uses the lower bit (OBJ_ALLOCATED_TAG) as something > special which is guaranteed to be zero due to memory alignment > requirements. The content of the memory, that long, is then used a bit > spinlock. >=20 > Moving it to spinlock_t would consume only 4 bytes of memory assuming > lockdep is off. It is then 4 bytes less than a long on 64 bits archs. > So we could do this if nobody disagrees. The spinlock_t has clearly > advantages over a bit spinlock like the "order" from the qspinlock > implementation. But then I have no idea what the contention here is. > With lockdep enabled the struct gets a little bigger which I assume was= to > avoid. But then only debug builds are affected so=E2=80=A6 First of all, thanks for the patch, Sebastian. The zsmalloc is usually used with swap and swap size is normally several GB above. Thus, adding per-page spinlock is rather expensive so I'd like = to consider the approach as last resort. About the lock contention, it's rar= e so spinlock wouldn't help it much. Let me try changing the bit lock into sleepable lock in PREEMPT_RT with=20 bigger granuarity.