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 60CE2C5478C for ; Wed, 28 Feb 2024 01:54:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A28E36B0273; Tue, 27 Feb 2024 20:54:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D7D46B0275; Tue, 27 Feb 2024 20:54:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A0176B0276; Tue, 27 Feb 2024 20:54:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7AC276B0273 for ; Tue, 27 Feb 2024 20:54:45 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3D1BD80DF7 for ; Wed, 28 Feb 2024 01:54:45 +0000 (UTC) X-FDA: 81839543730.18.7FCEABE Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf01.hostedemail.com (Postfix) with ESMTP id 7053F40005 for ; Wed, 28 Feb 2024 01:54:43 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=MsV4bHN0; spf=pass (imf01.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.167.175 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709085283; 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=Mc/Ezc697PEIA5Ksiw6r1nbfjVv1RcjD2G5KFRLlKic=; b=1G30cwmZKT3QmisEFH2v9TsuQVKHST59eJ9K2ClXrcVwuSCEUBG81B4v3oycOiQX4sjuqC DRsnhoyQUgWpXXVIfgO5gtygaxB32ntki+hmrY9dsmATe+dyn5q18Izk4UZROtmwEmp4Bq UJIcsqlyWqTVpQd9anMljXlq8K2CNm4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709085283; a=rsa-sha256; cv=none; b=VEOSiQWqcVEHhDScTqJMUgHbQ7MoI5bZTAKAVckkpUye6tp08kF+QciaI+dm7PCLvtfM45 z32ClHUF8DXMTHuwDSOMX1ohtxcZuHlWwDafLTgICjEuHSch4Q4xG+B/SGlcTJyXpLNOPv BjZEiDnYu6wfdfdeJa24SG8m9V9AYB4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=MsV4bHN0; spf=pass (imf01.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.167.175 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-3bbbc6b4ed1so4042976b6e.2 for ; Tue, 27 Feb 2024 17:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709085282; x=1709690082; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Mc/Ezc697PEIA5Ksiw6r1nbfjVv1RcjD2G5KFRLlKic=; b=MsV4bHN0aj2+wBS4tZ/tID2E41jnpxiuPexrxnG2I0p5kyioZcGLKyG9Hw+1YJ3U8+ mRZBjWWv13UyN74KUJsZGDv+MN6iCXzDwI12AEelzRpQ8rySjBHBOTvR5wYphXoj+NLd 3yzyDCpW+tuLGey2p85rdrI/WvPDXdMjIDjAQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709085282; x=1709690082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Mc/Ezc697PEIA5Ksiw6r1nbfjVv1RcjD2G5KFRLlKic=; b=tlwK9BsE8vJJKYI8S20HM21jAqyldPsYyVRYXR14xxDShUqd2xxsvNh0RM1c2tRtCd ypSgltOFsSqtrWXWXvL5lqB/vfnVcfqkI9utgoH154yl+HU9Rf2Wd2OCA/VM1F4K87pY 5ERXnSRshdJyb0GE/DHK1aYCvD8i16Zo1KvePlyzE9MkBRKLkubCDQDwTLQR8JyURTKF rc8o9MMV8QWUmOUIiL5fogeCMoRQtrt1RsLa/3wSZ+xD0ZRr2g5L255mZEijxQ8jeDQA 2ZXo1K3jye0cpqdsQxJa1r4BQLQCQN/IJQygHiiXNJkeXvlJfcJDx6X8lktsWQ8+/6+4 c8Hg== X-Forwarded-Encrypted: i=1; AJvYcCXliGmigMe7t8Z1yoweFcG202E65yxpHtUjfcxG/uQ6/oWs8kEkbzAESw8yYgKovCJk0p/aZ4Mh+YAI5cLXufq4sqo= X-Gm-Message-State: AOJu0YzVK+DubfPR02Zk3XjwVFDM6C/JgPwE9etsABsKdUUUTxT4yemz ohb/0ZKUhL/vqMWPJ3WW83NacINvC1XLDEm50a4ZAW8FOBjlBu6OBgo5LbluYg== X-Google-Smtp-Source: AGHT+IGyfyIJBYJTY8rklLWwv37s6BU98y6vjPcrG8g+PL/VK0zg6o62zicYugg3UHGVOU0ViEOYyA== X-Received: by 2002:a05:6808:54:b0:3c1:40f4:92f4 with SMTP id v20-20020a056808005400b003c140f492f4mr3285999oic.16.1709085282433; Tue, 27 Feb 2024 17:54:42 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:f4f0:fb4d:aa01:9068]) by smtp.gmail.com with ESMTPSA id y38-20020a056a00182600b006e56277fd45sm148915pfa.190.2024.02.27.17.54.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 17:54:41 -0800 (PST) Date: Wed, 28 Feb 2024 10:54:37 +0900 From: Sergey Senozhatsky To: Chengming Zhou Cc: Sergey Senozhatsky , minchan@kernel.org, akpm@linux-foundation.org, hannes@cmpxchg.org, nphamcs@gmail.com, yosryahmed@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chengming Zhou Subject: Re: [PATCH] mm/zsmalloc: don't need to save tag bit in handle Message-ID: <20240228015437.GB11972@google.com> References: <20240227030045.3443702-1-chengming.zhou@linux.dev> <20240227075209.GA11972@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 54cnyd3bodopsj4ekxko85c8yzyo8ysb X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7053F40005 X-Rspam-User: X-HE-Tag: 1709085283-554414 X-HE-Meta: U2FsdGVkX1+iFpaUa0GCdKU4P+5+gVRGDUdq3mFg5qJDUmEclRxwpvhclxToJl9VXPdsFrucIBhRKYJyI23pCId07HVvz5y9cFLv1g07u1BUYjgmL1Grj9Yq69v7/zkm6FuQ79AVEKM8s3Ts+9R3gFZHHLsYlS09SkJO9JHHGwacEnsDXOwNkmkwgtwiNbWs2YoiVXYfdScGDTuT/LaYC/39gwBDvDdxYKQksdaY6EB1SJ41WHlGZVMTX+mww86ynBW8YBvk0qFpA1R7bzQ3BKTu2eLoy4Ox87+U4K+hYImIaRdAs1fLj6R81nTMunWC5q6kz+QCv+gqVN00L17FXbzD3QVyP6i8fM6CYaOzj7sFybo7RA5z3LoqyGF8zuTGxxLt1j6S7Y4mVtvOyPLkCbmIKGxNIoDfzw6txEwO7XE3n+es7LP7Evbe1fxwf2BmBq/cKdudpYarwxB3gOHN+dPu6J/r2O9eHkSDXB96H6Eirer20BrZcjef6TPQcAGA8uKI9kFre2t9GmEnMlsXz5zMR8VSBa5ngP93bdqVjrFEG2LBCBLu4q8Wb1xRhsb2njGTtFTAVnUdFt8EHQ5Qxi4PdDvVSPAr0OeydXSSCQTNPsBjZPZrTNk+Kc6rnXkrN8sUFtxJ+7TRWppfAvrxAUdBjXmCAhA3RMUiaGwQfbNs6BUUUANIEsTnZm8ynooB2mCJvpQOrXzGKL+BFOU2o0daa9I4rudoUCka5aIOunABCFLZ7uPI6Ooi5gndmvXAzhiRoyLrf8Q9WPlSgDpPSY0u+EDtQ5klPqa2W+z1jOeJEy9tvOCF2Ya2jjVkRbM54e/zLs4b/vRru2I11cM7GSOSrSZaNQaFoBEIdaXCnbh93gf9ifveKrmfk4+6otdu0HelMeeOMMg7AMAvk3UXsGGSq3qanEePqqdCcDvmkKVr8ME6Qg9jmG+f98Jn9CCMPwCn3sb99Ccs9Tjmg/7 Rla4lBMN HPVTwTnCnLAO6daZ0WwtMLJvpMkjdrwdeHwnnGkrzmXGKZe+/kV0FVN1TCGusREgXUN5PkNIrVs4K6WM6H4sR+3Qy4rAn7LyXCWlHavow+WtsdSX5iaxUtT2SFFoxETX45+mJEJeEjWu8+xtdLKwT09yAfwZuz1x48qddVUs2FkXS5GM4zsSIz7aU8ztJpOnPBP+KS4Acyj4NtR6UtZkeATMPPgYbfxroDt4Idi90fn3zsuM08jmkCLLyIHH3C6yAEMuYOhawZNSNV5HLXkRrHJ6JaBNtEo8dYWAPfvCFQjsn0i30TYJNVKH/wIeexItxrk6P X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, 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 (24/02/27 16:16), Chengming Zhou wrote: > On 2024/2/27 15:52, Sergey Senozhatsky wrote: > > On (24/02/27 03:00), chengming.zhou@linux.dev wrote: > >> > >> We only need to save the position (pfn + obj_idx) in the handle, don't > >> need to save tag bit in handle. So one more bit can be used as obj_idx. > > > > [..] > > > >> mm/zsmalloc: don't need to save tag bit in handle > > > > Does this mean "don't need to reserve LSB for tag"? > The head of object still need to reverve LSB, to save (handle | OBJ_ALLOCATED_TAG), > only the handle doesn't need to reserve LSB, which save (pfn | obj_idx). Correct. > > We still save allocated tag in the handle, that's what > > > > handle |= OBJ_ALLOCATED_TAG; > > Yes, this result will be saved in the head of each allocated object. Right, that's what I was talking about. > >> Actually, the tag bit is only useful in zspage's memory space, to tell > >> if an object is allocated or not. > > > > I'm not completely sure if I follow this sentence. > > What I mean is that only the head of each allocated object need to reverve LSB, > which is used to check if allocated or not. > > handle address -> handle (pfn + obj_idx) -> object: (handle | tag), real_object start > > I'm not sure if this makes it clearer? Yes, thanks. I think separating handle and object header in the commit message will be helpful.