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 A65F3C433EF for ; Tue, 5 Oct 2021 23:00:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4913A61165 for ; Tue, 5 Oct 2021 23:00:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4913A61165 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BA0356B0071; Tue, 5 Oct 2021 19:00:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4E536B0073; Tue, 5 Oct 2021 19:00:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A65856B0074; Tue, 5 Oct 2021 19:00:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 9871F6B0071 for ; Tue, 5 Oct 2021 19:00:35 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 62370183C7652 for ; Tue, 5 Oct 2021 23:00:35 +0000 (UTC) X-FDA: 78663904830.16.820A5DD Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf15.hostedemail.com (Postfix) with ESMTP id 0701BD0017CD for ; Tue, 5 Oct 2021 23:00:34 +0000 (UTC) Received: by mail-qk1-f182.google.com with SMTP id 72so632497qkk.7 for ; Tue, 05 Oct 2021 16:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=c27OGSujHgzp+uK3WrYPrd2rCSZ0Tk1tcB9PQMTc5zY=; b=fvojdOjqWsxsoXwrgzMnTVRDKItoHFcrc5OlMIfMEunwosYVr+A4RYqQdDhHHWzFLK AVYtlp5lxyfzphV1ofqFDidgboCi5IhCxSssYJIrZNg81qH9SlNozd+2Daol90y9jUHS 55xKuTVLg5wsZWjmRo62FyyV97MmHah8NuWMeNS+owgZJITILBOkY1GWOJaBnYkMKYE5 suTT0nQbU2N//kIMru2tOsZEMWcqKwZW+sgR8HPqDFP/PHiMIUN8+wQfDNA7JASAq08j vjhH9+V9WXHbIddRobWlhEKxWKg+sxnJWu9ZcbuQEsg2+VgxiYRlLJNEJs9bxCfk+5db VwNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=c27OGSujHgzp+uK3WrYPrd2rCSZ0Tk1tcB9PQMTc5zY=; b=Gb1lCm0/YpzDfppsNbhUvmbkI7GlaKdPZfq3Tard4/pLfBZrH6c2v5t9JAc9z+wdY1 i4eJm2h1ymLW7x9MVQZqbIkmHYgugS4AV8a+kckGZg4gOlVCEyW+0x5+F8m0Z27zFFVQ FrXyM24RLEACD82avj03s6noLbNnzXFjbvRfc8ezbpYg88GuoIj9p4ZRl78O+xG/J6gN UBf+jQf5BRdUiuDACJMI7haty1AICUiiB7bNueU66zTq+CQhfM4ibog6FZUREJR7Y55W d841C6utho2tDJ0Fi6Lw2fhC6XcH1c0GrmxWaeFPSFDWMnCq/EMjYs3uFFvatWrD0+DN mczA== X-Gm-Message-State: AOAM531+RcnWf/URVBbctvagwnyzjZ5jgJuwOhJVyX5bfEq55pQ0fq2M eKYVwKG9PZIeXdOxl9w8rQ== X-Google-Smtp-Source: ABdhPJwTrkemEFb2Jw+55bsRBx9F8J2yeI3HbVUrSeMrwsR5TD6QDmyAkAnxaqgRofT6C5EBQV5x1A== X-Received: by 2002:a05:620a:6a3:: with SMTP id i3mr17284407qkh.483.1633474834186; Tue, 05 Oct 2021 16:00:34 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id c3sm11070976qtp.58.2021.10.05.16.00.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 16:00:33 -0700 (PDT) Date: Tue, 5 Oct 2021 19:00:31 -0400 From: Kent Overstreet To: Matthew Wilcox Cc: linux-mm@kvack.org, Minchan Kim , Nitin Gupta , Sergey Senozhatsky , Johannes Weiner Subject: Re: pageless memory & zsmalloc Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0701BD0017CD X-Stat-Signature: xtgu8rfr13mkcmiyi6b7b8xrcouhqfgt Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fvojdOjq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com X-HE-Tag: 1633474834-351105 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, Oct 05, 2021 at 10:28:23PM +0100, Matthew Wilcox wrote: > I'm still not convinced of the need for allocator + allocatee words. > But I don't think we need to resolve that point of disagreement in > order to make progress towards the things we do agree on. It's not so much that I disagree, I just don't see how your one-word idea is possible and you haven't outlined it :) Can you sketch it out for us? > > And in my mind, compound_head is allocator state, not allocatee state, and it's > > always been using for getting to the head page, which... this is not, so using > > it this way, as slick as it is... eh, not sure that's quite what we want to do. > > In my mind, in the future where all memory descriptors are dynamically > allocated, when we allocate an order-3 page, we initialise the > 'allocatee state' of each of the 8 consecutive pages to point to the > memory descriptor that we just allocated. We probably also encode the > type of the memory descriptor in the allocatee state (I think we've > probably got about 5 bits for that). Yep, I've been envisioning using the low bits of the pointer to the allocatee state as a type tag. Where does compound_order go, though? > The lock state has to be in the memory descriptor. It can't be in the > individual page. So I think all memory descriptors needs to start with > a flags word. Memory compaction could refrain from locking pages if > the memory descriptor is of the wrong type, of course. Memory compaction inherently has to switch on the allocatee type, so if the page is of a type that can't be migrated, it would make sense to just not bother with locking it. On the other hand, the type isn't stable without first locking the page. There's another synchronization thing we have to work out: with the lock behind a pointer, we can race with the page, and the allocatee state, being freed. Which implies that we're always going to have to RCU-free allocatee state, and that after chasing the pointer and taking the lock we'll have to check that the page is still a member of that allocatee state. This race is something that we'll have to handle every place we deref the allocatee state pointer - and in many cases we won't want to lock the allocatee state, so page->ref will also have to be part of this common page allocatee state. > Eventually, I think lock_page() disappears in favour of folio_lock(). > That doesn't quite work for compaction, but maybe we could do something > like this ... Question is, do other types of pages besides just folios need lock_page() and get_page()? If so, maybe folio_lock() doesn't make sense at all and we should just have functions that operate on your (expanded, to include a refcount) pgflags_t.