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 65456C433F5 for ; Fri, 18 Feb 2022 10:13:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9DDD6B0074; Fri, 18 Feb 2022 05:13:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B4D266B0075; Fri, 18 Feb 2022 05:13:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9ED376B0078; Fri, 18 Feb 2022 05:13:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 8D1B16B0074 for ; Fri, 18 Feb 2022 05:13:36 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 47BB1180D3314 for ; Fri, 18 Feb 2022 10:13:36 +0000 (UTC) X-FDA: 79155488832.12.C32C7C8 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf28.hostedemail.com (Postfix) with ESMTP id CC126C0005 for ; Fri, 18 Feb 2022 10:13:35 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id b8so8135502pjb.4 for ; Fri, 18 Feb 2022 02:13:35 -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=1PKhL/9YxVh44Q8mJ2k9mFL0NfcXYRcMNcar+n3ctso=; b=B+V1TX06hO7yCTDcwWv1oOU8qPNwVKVSZAOtzncFeznx+dbcYcNw7EgUbZhCqOncHE v07rLC4MeWFX2F7hwBkI1VJCKIPIy5Ef6fty6j0rsRyg1QnFHJIQihmylTkAKmuBTEFN FQ8JC410OGtNTk8gZr+umUw0FnV78fqcuDl7rgniPqygdLBM2Nk4jSZnQxuMQVgRp0kq UfD7BUOs6si5i6YmhVdSxxHtcYuRefsaXUHRTLT53TYe2s2XXzbDQ30YqB+g5bEzFNIm 3tLColl7XhgKpDgFrUvPTHSUgq0uEmOSBXHlmyGciCppxMSY8OcOQyBmX7bv1ASyc+jF 5cqA== 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=1PKhL/9YxVh44Q8mJ2k9mFL0NfcXYRcMNcar+n3ctso=; b=ZluWb8eYNG5TF36NQEdw71c46lKMRfac0kdL3tCsBPFfOseFTqvXYxkH1QXH95SRav bAJPlDJK4h0w4gA+OVHLxwFl+IhxpcdVotqRwgEMFXsRApuO7KAzRx8ZyLjGehCMhIel a9DSBzbrd40KVn1Ol37RWdf+zK9e4eH9gP/phVqLmLGhy7FJR9go1J4sSwndHIFqzbfR hSH4cQtSu0ZUyQzIt+mhhn1P/MbIYatDDURxygNru1t/1rRi6dSIk8esIO9njY+Y9l4g p8EHVKZA5b6VSdEYeWKEqvOP3U/8eYyAFZjbQN3LCE6EST3Z8fW4i7O3FVYqz1mPl9As bpaA== X-Gm-Message-State: AOAM533FGqo21dHglKRKt0Zk4AMl1iHWfvO51qP8Q9FYMxY3RQBFegzK 89LbIrGmUktuc90lsniNvLw= X-Google-Smtp-Source: ABdhPJxcY9wJZv/QU9AS+Ztdz6u/swmfTAQm+kxu19oxkxM5a7MSxqJP7i7VJvqnFX3D6YmfBE2olA== X-Received: by 2002:a17:90a:ec10:b0:1b8:9da7:3d13 with SMTP id l16-20020a17090aec1000b001b89da73d13mr7641603pjy.194.1645179214682; Fri, 18 Feb 2022 02:13:34 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id x4sm4398484pjq.2.2022.02.18.02.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Feb 2022 02:13:34 -0800 (PST) Date: Fri, 18 Feb 2022 10:13:29 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: Christoph Lameter , Matthew Wilcox , Christoph Lameter , Linux Memory Management List , LKML , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton Subject: Re: Do we really need SLOB nowdays? Message-ID: References: <20211028100414.GA2928@kvm.asia-northeast3-a.c.our-ratio-313919.internal> <20211210110835.GA632811@odroid> <20211215062904.GA1150813@odroid> <54c6fff8-8c79-463b-a359-96e37bd13674@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54c6fff8-8c79-463b-a359-96e37bd13674@suse.cz> X-Rspamd-Queue-Id: CC126C0005 X-Stat-Signature: 6tky35bxyaunj3ixy4piyc6a37dc38io X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=B+V1TX06; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1645179215-355278 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 Wed, Dec 15, 2021 at 11:10:06AM +0100, Vlastimil Babka wrote: > On 12/15/21 07:29, Hyeonggon Yoo wrote: > > On Tue, Dec 14, 2021 at 06:24:58PM +0100, Vlastimil Babka wrote: > >> On 12/10/21 13:06, Christoph Lameter wrote: > >> > On Fri, 10 Dec 2021, Hyeonggon Yoo wrote: > >> > > >> >> > > (But I still have doubt if we can run linux on machines like that.) > >> >> > > >> >> > I sent you a series of articles about making Linux run in 1MB. > >> >> > >> >> After some time playing with the size of kernel, > >> >> I was able to run linux in 6.6MiB of RAM. and the SLOB used > >> >> around 300KiB of memory. > >> > > >> > What is the minimal size you need for SLUB? > >> > > > > I don't know why Christoph's mail is not in my mailbox. maybe I deleted it > > by mistake or I'm not cc-ed. > > > > Anyway, I tried to measure this again with SLUB and SLOB. > > > > SLUB uses few hundreds of bytes than SLOB. > > > > There isn't much difference in 'Memory required to boot'. > > (interestingly SLUB requires less) > > > > 'Memory required to boot' is measured by reducing memory > > until it says 'System is deadlocked on memory'. I don't know > > exact reason why they differ. > > > > Note that the configuration is based on tinyconfig and > > I added initramfs support + tty layer (+ uart driver) + procfs support, > > + ELF binary support + etc. > > > > there isn't even block layer, but it's good starting point to see > > what happens in small system. > > > > SLOB: > > > > Memory required to boot: 6950K > > > > Slab: 368 kB > > > > SLUB: > > Memory required to boot: 6800K > > > > Slab: 552 kB > > > > SLUB with slab merging: > > > > Slab: 536 kB > > 168kB different on a system with less than 8MB memory looks rather > significant to me to simply delete SLOB, I'm afraid. Just FYI... Some experiment based on v5.17-rc3: SLOB: Slab: 388 kB SLUB: Slab: 540 kB (+152kb) SLUB with s->min_partial = 0: Slab: 452 kB (+64kb) SLUB with s->min_partial = 0 && slub_max_order = 0: Slab: 436 kB (+48kb) SLUB with s->min_partial = 0 && slub_max_order = 0 + merging slabs crazily (just ignore SLAB_NEVER_MERGE/SLAB_MERGE_SAME): Slab: 408 kB (+20kb) Decreasing further seem to be hard and I guess +20kb are due to partial slabs. I think SLUB can be memory-efficient as SLOB. Is SLOB (Address-Ordered next fit) stronger to fragmentation than SLUB?