Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2816738pxb; Mon, 18 Oct 2021 02:28:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGyOX3zOSI8GivaKpdhdGrWtPiwyw+XYpS2E3njK/OV2p9xqwh4DETBWN19oKkUAZQdVnm X-Received: by 2002:a50:d511:: with SMTP id u17mr42032175edi.105.1634549296404; Mon, 18 Oct 2021 02:28:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634549296; cv=none; d=google.com; s=arc-20160816; b=cKp5zl83TmTmTIX3CRqkLt5QA898kM0ZbOyVU62P2+083IPlMlIv8yQiIcOviwbHER xZiAnnoXejftIzhAbz6mvTUBaoRIUerM3n0V4tUtch8iAqv4kJoUYxHrSf0citpS6rB9 4ZZxpHTqSsrDn3uROXdYN955E2spQoqJe/XLGU7DEsMlyP93qWsJzobotswk3+0BI6dl qp8O2N8Zl49SWhC57JRvAJLhXkNH2TdognSnjd2wfhRZvAVGA6W0uC7E+TBg+Yg8FFOG bTWikPEgHtNF10gIQbMppYs7PBYj4QvhKV4/isJnWdwavOvKSfjgsy5QD83WJ6SG40gp 61hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature:dkim-signature; bh=8Fcnlx2WieTP93iZwOM0gAJT8K7I1qMUMTJBSVqOvvk=; b=vSzzzqU3avf1EGLQrMnzr3NI91TEaip0qLsFUAlrPofLVA2p/J2vNet5Q4EI+leN3j pMBYnzGBLvkAMN/gqcAW8RJJ58jktZlKnstPN0xbcUOfxoIZrbCiSNWFV/I+FlEMSqGS xtKC1hPxYhEJNheJ9Bi2sHQQZRPPGiC57DZ8pjohj9du/ZWZPoR1FsnRHQuccOB4McQu BKoRR5FT/98M9h6cIPzT09rqEULve551GTz4csluE4uF9xw0EyA8FcrBPLZFxA1KN8Yr Xjl4BPGH2ZQfRkxVpGQ3Eg1qkRIo9aJ7a12dZiO8GULuYJTM9Dsu/LDxxeWAO8vN9sau G4/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=NfZzymmI; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e15si4106030edz.264.2021.10.18.02.27.53; Mon, 18 Oct 2021 02:28:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=NfZzymmI; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231517AbhJRJZW (ORCPT + 99 others); Mon, 18 Oct 2021 05:25:22 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:59826 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231533AbhJRJY7 (ORCPT ); Mon, 18 Oct 2021 05:24:59 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E82921FD6E; Mon, 18 Oct 2021 09:22:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1634548966; h=from:from:reply-to: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; bh=8Fcnlx2WieTP93iZwOM0gAJT8K7I1qMUMTJBSVqOvvk=; b=NfZzymmIfekjz8mE2Ol4wuMwyeQnK6bK3DPLmHt4xJ1/8BsJLCiX95MSNobrs4ymzwE9ia actWg1VCK5bJ46yjdYCOVO876If+xCDObtMOayjAt+W/dXoMTlSnR4YuO+YEgcGhtRERA9 Tm1Zysjtwayv9hjRyjkxG8ia0OYt4uM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1634548966; h=from:from:reply-to: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; bh=8Fcnlx2WieTP93iZwOM0gAJT8K7I1qMUMTJBSVqOvvk=; b=dYl0Kes9sfmVtSwI20o18h+rhzeX/aZ2WBPhGjfAdJ6IXke5qoxyCOTWSS/OK9WCNzMpwt fvyE6y8OpoPlTkBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A2B7B13D0C; Mon, 18 Oct 2021 09:22:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NijWJuY8bWF2SgAAMHmgww (envelope-from ); Mon, 18 Oct 2021 09:22:46 +0000 Message-ID: <20758764-8139-ab0b-a782-dc63559b43ba@suse.cz> Date: Mon, 18 Oct 2021 11:22:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Rustam Kovhaev , cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org Cc: djwong@kernel.org, david@fromorbit.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, viro@zeniv.linux.org.uk, dvyukov@google.com References: <20211015005729.GD24333@magnolia> <20211018033841.3027515-1-rkovhaev@gmail.com> From: Vlastimil Babka Subject: Re: [PATCH] slob: add size header to all allocations In-Reply-To: <20211018033841.3027515-1-rkovhaev@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/18/21 05:38, Rustam Kovhaev wrote: > Let's prepend all allocations of (PAGE_SIZE - align_offset) and less > with the size header. This way kmem_cache_alloc() memory can be freed > with kfree() and the other way around, as long as they are less than > (PAGE_SIZE - align_offset). This size limitation seems like an unnecessary gotcha. Couldn't we make these large allocations in slob_alloc_node() (that use slob_new_pages() directly) similar enough to large kmalloc() ones, so that kfree() can recognize them and free properly? AFAICS it might mean just adding __GFP_COMP to make sure there's a compound order stored, as these already don't seem to set PageSlab. > The main reason for this change is to simplify SLOB a little bit, make > it a bit easier to debug whenever something goes wrong. I would say the main reason is to simplify the slab API and guarantee that both kmem_cache_alloc() and kmalloc() can be freed by kfree(). We should also update the comments at top of slob.c to reflect the change. And Documentation/core-api/memory-allocation.rst (the last paragraph). > meminfo right after the system boot, without the patch: > Slab: 35500 kB > > the same, with the patch: > Slab: 36396 kB 2.5% increase, hopefully acceptable. Thanks!