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 6FDC5CF6493 for ; Sat, 28 Sep 2024 08:12:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C76546B019C; Sat, 28 Sep 2024 04:12:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C26746B019D; Sat, 28 Sep 2024 04:12:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC6B26B019E; Sat, 28 Sep 2024 04:12:45 -0400 (EDT) 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 8E5466B019C for ; Sat, 28 Sep 2024 04:12:45 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3A7A98180C for ; Sat, 28 Sep 2024 08:12:45 +0000 (UTC) X-FDA: 82613430690.07.29F95DA Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf29.hostedemail.com (Postfix) with ESMTP id 6285E120003 for ; Sat, 28 Sep 2024 08:12:43 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="s/fmAsOd"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727511027; 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=Samd0mUAzWlzelumq96uezolPu6N8J4V2/Xoj2xIqfQ=; b=APkwz5JP2uzKt4gsdQ79XwdpB66YA/FTn9ULsWqmPaIvzE6sp00arlkUAaaGmUEledoDH6 cAfju2PttNhKUQ91j9TPQMdhzH2n18ehcee96Zok1JNgMyGo7BAG8hVy8MCxHF9ZepiMbN mrTzT52i4wd4Tu0T9iGHOFsU/lrf1aQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727511027; a=rsa-sha256; cv=none; b=aADUAJC/5vFfEK8Us7lm6VFVSObIxc84WCFjM/MIIscGjpD1hBVyOgdZC4jrcLiGQekc3e SgphVnnMQMZTNEOkMd5PgYOB5sF7QJa04ZICJwcFM0cW69WzAiCxBeT//nVhm0sdypEpT4 usl5nMuDthV7PUbAc3V9NLe59S9n+g0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="s/fmAsOd"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a8a7cdfdd80so412385866b.0 for ; Sat, 28 Sep 2024 01:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727511162; x=1728115962; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Samd0mUAzWlzelumq96uezolPu6N8J4V2/Xoj2xIqfQ=; b=s/fmAsOdGCLO52FUoEiVjZ25JP2PbGq/QZiqu4WleEPRUCWExM64z1ZlmBtnSVyyA1 xqKwdcCN4SGrodmn7sxmeKILU37RyF/IbMNXf2GkKFR1vwDu3SnxdCKQrzwMGtOMVBP6 dgDkVAzTRJDUWTs/oORMIb7OpK1YQf6/Ed4s83ojOiooQPyuxhbH24Y1/Bvh80I9Ohdq KpDLAHnL1bylxFGk30sSxCYeM5BXSfxGfZTj8ec7nGrj6P81KUykVxhFjYVhSMrfdtHn 59W/S3thf5rZzzBbTKGLJ+1cmDItbX3itwP8dE7zRDRS7Khm6BOnprUB6xAZ4GRhqBwi 7dug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727511162; x=1728115962; h=content-transfer-encoding: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=Samd0mUAzWlzelumq96uezolPu6N8J4V2/Xoj2xIqfQ=; b=gffjGwy4OpgARyDvTQrefgkLaSx/c4Kzg/gD1u4Xthri02tivfdztcnF6e+LAz8Zy9 As+g0eMIR48LW/gSB4Ft4r67lVJlx+gqsesgNwaFWoKsvwmI19h34LPy5EBamqfN+wsH wfWzPojSxXM3u1GDpSUmkbUX5JAnWHtm0xVEa6ri6HkceQfBfmqe+tOLejaRWJgyiVCd bi/rVO4NYFzVfU05NZpWRcRmCwMl08PdlsQN5k1x8NpVyfRaj3a77YnK9w/1IOC6/r9/ HfJBAy+RY76QIuaAKmpl4rJzoQZwrCDn9GILLVHlTuHXr753/n7K3aNbVozlXQo9npZF ERjg== X-Forwarded-Encrypted: i=1; AJvYcCUNvuUkwLSdac3GlWMoCMcw+WwiBD9QKPwgOlEYF9W1h4wwJUHJ6R9WiyCbcWJG6mQKeHOyBTGjlA==@kvack.org X-Gm-Message-State: AOJu0YzOMU4Tko781Ob6uoLLayx/iB2QcSytUHkOYHmD2jqe47e6vJF4 eTDMVB5YyzhKc8gg7sb2dnG7nDgXG5c237NLQ03QRnpoAX5qE6RfuXviVXCFCwxbvQWCqCPJie1 i4p4G3Am7IGYfh9RiqVHW4oYH5b4hSagQ7obf X-Google-Smtp-Source: AGHT+IFty7FKqvcT4C7Q34oUTNws54WXjoXhfG6q3VK0rE1eH8IpvJ53SMpi9glnL4Jkh1DXThecgIWksBjhtG8ER20= X-Received: by 2002:a17:907:7da7:b0:a8d:439d:5c3c with SMTP id a640c23a62f3a-a93c48efd0fmr608359466b.8.1727511161494; Sat, 28 Sep 2024 01:12:41 -0700 (PDT) MIME-Version: 1.0 References: <20240928021620.8369-1-kanchana.p.sridhar@intel.com> <20240928021620.8369-6-kanchana.p.sridhar@intel.com> In-Reply-To: From: Yosry Ahmed Date: Sat, 28 Sep 2024 01:12:04 -0700 Message-ID: Subject: Re: [PATCH v8 5/8] mm: zswap: Modify zswap_stored_pages to be atomic_long_t. To: Matthew Wilcox Cc: Kanchana P Sridhar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, nphamcs@gmail.com, chengming.zhou@linux.dev, usamaarif642@gmail.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, 21cnbao@gmail.com, akpm@linux-foundation.org, nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6285E120003 X-Stat-Signature: 974xjp37fp3j3asebimj1yffbf391k9i X-Rspam-User: X-HE-Tag: 1727511163-321260 X-HE-Meta: U2FsdGVkX18MiCkffZ3PJ1YCI90ALl0bBsGCmHkr3wysny87WuLazV6pSoTHo5wsx2Hs2mHtrpz+MLplsuSZvrcMCzlzw6x376IdHHoq+ZYZ3VRLSUp/W34n11T85zRl4gvuFxywHA9m6mQfY+958hVNYNAbJ76FB0WhLstwzUdbUkMiaFNAmPns7rVxCLzOW4/fLpeeAHHTM/g3+TigICw8bxeO3/krsthtmSOfqW+/7c21MuzKjtR3bsROCPSEvXJalzo4569+TKtsXvuUPx8G3VjqK+1iPMJLfFN8eF6o1DMyBqV1WPWg+u9aeInrXfR106cQzwagEMpcRgZV8ncVVkYnjGtRMrQOWCmoKtz0t2PvBIgkgJ1XmGKAg6vuxOfuJy1VK94sp/R7zMJp7VlhVTgus78sCg29HVz3j/RVlMRD+1JtTnCzApMFECReX8d1P3nIAi4fLRMv1vudc3pG5yMwe0Ul7DtJBnY9OicdYLmr327ZYUUANXz9I66r1sHQr06Klzk9L5W7l92K7SP3Dn31ILA3JT4c0qsqYmzmVKBkVXOuez0lzeSSuibVyeJod/foASxs8nwLEzjUecK8nGVbZC8J40UD/xyXcrhTYGZyz3WiTYSK2MOrUdOBSC2Ebj2fmX0euL2UqKdkBYJJD6iKDCUJEZEUrBEaA35YuMFmDg4EE7ioQvOAi7YE60TEbjP3jNqYRj8OdBYXQpO7sGlPDoumvpS0xxR9TVYOmPMrRPMbddPjktkzaoKfnvDomYzPFRcTig0ys8rZYn4z/okMjVpJGd7HVXgbfKaS039MHj4OVIRc+zBZGRhKjiuQuQVikePFXBEtRRGoBVgK3qJvJY69AVhQPBUZgwnl13OigXFWitWnyrOCHMSCDawM1kwUVW1MjyyfwZpej14EAq09gJVvfZhXE1jc2tC5fH9pE+fvpVj5IefrZJE8rLqFES175qNrB1ds69b ZygMWl/g haFl9N3X4f9Yej4Q+mIXbs/0YPfP8ciaYW15kCJlIY5jU3msSkITUNzkSw/rYLIUEr+F32N8q544RrFluy8tuJHJ3nLnDiUCN7jBc83D0Erx46ZLOf0kp/n6VnJOtHx60BGQdi0VNSTxDxGrmNoN1+bnmpz2vE0oGEUgYNKiRQvlrrkj7X2jOlwk2oGtYy9FaJGs2XVi9NbulqadYees3sAO8/DAY/qo/RE8C1Cz3LQvE5YMsn4WuLu9wPup2FgRK2VFoX4Enw1IAWKnRQZxyiy3b9IbQ0h46U16eME3NGeDUagHyXtN/E69suMz0CP9k1r/GXEZlrLJmAJ4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, 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 Fri, Sep 27, 2024 at 9:51=E2=80=AFPM Matthew Wilcox wrote: > > On Fri, Sep 27, 2024 at 07:57:49PM -0700, Yosry Ahmed wrote: > > On Fri, Sep 27, 2024 at 7:16=E2=80=AFPM Kanchana P Sridhar > > wrote: > > > > > > For zswap_store() to support large folios, we need to be able to do > > > a batch update of zswap_stored_pages upon successful store of all pag= es > > > in the folio. For this, we need to add folio_nr_pages(), which return= s > > > a long, to zswap_stored_pages. > > > > Do we really need this? A lot of places in the kernel assign the > > result of folio_nr_pages() to an int (thp_nr_pages(), > > split_huge_pages_all(), etc). I don't think we need to worry about > > folio_nr_pages() exceeding INT_MAX for a while. > > You'd be surprised. Let's assume we add support for PUD-sized pages > (personally I think this is too large to make sense, but some people can'= t > be told). On arm64, we can have a 64kB page size, so that's 13 bits per > level for a total of 2^26 pages per PUD. That feels uncomfortable close > to 2^32 to me. > > Anywhere you've found that's using an int to store folio_nr_pages() is > somewhere we should probably switch to long. There are a lot of them: rmap.c, shmem.c, khugepaged.c, etc. > And this, btw, is why I've > moved from using an int to store folio_size() to using size_t. A PMD is > already 512MB (with a 64KB page size), and so a PUD will be 4TB. Thanks for pointing this out. I assumed the presence of many places using int to store folio_nr_pages() means that it's a general assumption. Also, if we think it's possible that a single folio size may approach INT_MAX, then we are in bigger trouble for zswap_stored_pages, because that's the total number of pages stored in zswap on the entire system. That's much more likely to exceed INT_MAX than a single folio. > > thp_nr_pages() is not a good example. I'll be happy when we kill it; > we're actually almost there. Yeah I can only see 2 callers.