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 633BAC433EF for ; Tue, 30 Nov 2021 07:00:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBDF66B0073; Tue, 30 Nov 2021 02:00:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C6E9A6B0074; Tue, 30 Nov 2021 02:00:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B35776B0075; Tue, 30 Nov 2021 02:00:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id A5B336B0073 for ; Tue, 30 Nov 2021 02:00:36 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6DF5A18458A99 for ; Tue, 30 Nov 2021 07:00:26 +0000 (UTC) X-FDA: 78864698052.16.9173612 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf25.hostedemail.com (Postfix) with ESMTP id 3B7F3B0002B7 for ; Tue, 30 Nov 2021 07:00:21 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id b13so14193787plg.2 for ; Mon, 29 Nov 2021 23:00:25 -0800 (PST) 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=6Ik+pTXtKv34fQ1UUZbZJZdZn+WHDSuZ6kofV1okOnA=; b=NtO9cgLQf2lht5QwgP5kQgfCy5TEkHwrUsWgpMxpT6RZnIs06XfDoQh+g5LCAuPsM/ 9CB+5N+wqlhv2psXcvx6zupEp0KM6NLmb0UBTwj+p+TkY30FcwS5zuRk9Vh/jHowwoe7 eBz6yS0AbjU0zC/RW6XtnOEdKhlllYTnXH3+qiGXFHCPXaNdD1gTU1R1DWR8053P8Xbj gMnS89BNfqXU15vxaDFyl2+vOaMk5qrVsM6PkPXT9NyOrn/mJPIoCZKJEnvduckGUJa1 IFoAjJb8L6N3iQ/GiAxpM/BWRHtjUyKLAGRTm9XDUDKvwWbbFeExS0cpIL31FeVROvN7 mSew== 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=6Ik+pTXtKv34fQ1UUZbZJZdZn+WHDSuZ6kofV1okOnA=; b=QSkEjRev6wQGUQNFPo506pFZtIsl4QUt9ZE/oD+vFtc54GLIKAvKAcVvJmjfIWK5EB O7nhXqlJ9dBfsahaMjOtMpeleZLHV1tnD0JstQz2Y/+nP7K8IuMhXmQPSpaiHxLBT+tz h0HN6B01TjLR4/K4dUGjJPWyePIwh+2r+/RmRB5o8t6PTKadsDI1tjfGFsIGNi1B1gQc jmxE4s75p8o5xdhA+19ZBt6MD0uLuB6/h1rnLKDli9KO+LEoz/07HSFa9A8cMNLpZweW yorsh3e+KfWB8fVI6FJVMDqZcyOuwEBWXDHomR4S3zVcZmEi8K0CQAhIQIX0PcVrnaNG dq0A== X-Gm-Message-State: AOAM533VIU5YKlfhmCqYT2dmsAz8dZiVWQ9RZUrQfahuRcXWMEHjw++3 vpSGgmMujzxCbe+vu72tQX8= X-Google-Smtp-Source: ABdhPJw6XOKgF2a0sxCetttKNHnczXGM4q8FxPI8/XTkSBCL/Jv1sQ8rxU5o9mf9sC4eADXgnpNEbA== X-Received: by 2002:a17:90b:1185:: with SMTP id gk5mr3835435pjb.113.1638255624984; Mon, 29 Nov 2021 23:00:24 -0800 (PST) Received: from nuc10 (d50-92-229-34.bchsia.telus.net. [50.92.229.34]) by smtp.gmail.com with ESMTPSA id t38sm20093098pfg.218.2021.11.29.23.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Nov 2021 23:00:24 -0800 (PST) Date: Mon, 29 Nov 2021 23:00:22 -0800 From: Rustam Kovhaev To: David Laight Cc: 'Vlastimil Babka' , Christoph Lameter , "penberg@kernel.org" , "rientjes@google.com" , "iamjoonsoo.kim@lge.com" , "akpm@linux-foundation.org" , "corbet@lwn.net" , "djwong@kernel.org" , "david@fromorbit.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-doc@vger.kernel.org" , "gregkh@linuxfoundation.org" , "viro@zeniv.linux.org.uk" , "dvyukov@google.com" Subject: Re: [PATCH v4] slob: add size header to all allocations Message-ID: References: <037227db-c869-7d9c-65e8-8f5f8682171d@suse.cz> <20211122013026.909933-1-rkovhaev@gmail.com> <3c996e22-034f-1013-3978-1f786aae38fb@suse.cz> <148d2774-77b9-bb25-c132-80b00e16ea06@suse.cz> <69fc0cead9774dfdba816a8e25f30a53@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69fc0cead9774dfdba816a8e25f30a53@AcuMS.aculab.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3B7F3B0002B7 X-Stat-Signature: jko5qkqbnwqy3qkf5dgkobnkcjxpty53 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NtO9cgLQ; spf=pass (imf25.hostedemail.com: domain of rkovhaev@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=rkovhaev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1638255621-334183 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, Nov 23, 2021 at 10:18:27AM +0000, David Laight wrote: > From: Vlastimil Babka > > Sent: 22 November 2021 10:46 > > > > On 11/22/21 11:36, Christoph Lameter wrote: > > > On Mon, 22 Nov 2021, Vlastimil Babka wrote: > > > > > >> But it seems there's no reason we couldn't do better? I.e. use the value of > > >> SLOB_HDR_SIZE only to align the beginning of actual object (and name the > > >> define different than SLOB_HDR_SIZE). But the size of the header, where we > > >> store the object lenght could be just a native word - 4 bytes on 32bit, 8 on > > >> 64bit. The address of the header shouldn't have a reason to be also aligned > > >> to ARCH_KMALLOC_MINALIGN / ARCH_SLAB_MINALIGN as only SLOB itself processes > > >> it and not the slab consumers which rely on those alignments? > > > > > > Well the best way would be to put it at the end of the object in order to > > > avoid the alignment problem. This is a particular issue with SLOB because > > > it allows multiple types of objects in a single page frame. > > > > > > If only one type of object would be allowed then the object size etc can > > > be stored in the page struct. > > Or just a single byte that is the index of the associated free list structure. > For 32bit and for the smaller kmalloc() area it may be reasonable to have > a separate array indexed by the page of the address. > > > > So I guess placement at the beginning cannot be avoided. That in turn runs > > > into trouble with the DMA requirements on some platforms where the > > > beginning of the object has to be cache line aligned. > > > > It's no problem to have the real beginning of the object aligned, and the > > prepended header not. > > I'm not sure that helps. > The header can't share a cache line with the previous item (because it > might be mapped for DMA) so will always take a full cache line. I thought that DMA API allocates buffers that are larger than page size. DMA pool seems to be able to give out smaller buffers, but underneath it seems to be calling page allocator. The SLOB objects that have this header are all less than page size, and they cannot end up in DMA code paths, or can they? > > There might me some strange scheme where you put the size at the end > and the offset of the 'last end' into the page struct. > The DMA API should let you safely read the size from an allocated > buffer - but you can't modify it. > > There is also all the code that allocates 'power of 2' sized buffers > under the assumption they are efficient - as soon as you add a size > field that assumption just causes the sizes of item to (often) double. > > David > > > The code already does that before this patch for the > > kmalloc power-of-two alignments, where e.g. the object can be aligned to 256 > > bytes, but the prepended header to a smaller ARCH_KMALLOC_MINALIGN / > > ARCH_SLAB_MINALIGN. > > > > > I dont know but it seems that making slob that sophisticated is counter > > > productive. Remove SLOB? > > > > I wouldn't mind, but somebody might :) > > > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)