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 C9764C07E98 for ; Wed, 29 Nov 2023 13:25:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54F5F6B03DE; Wed, 29 Nov 2023 08:25:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FFF96B03DF; Wed, 29 Nov 2023 08:25:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C7276B03E0; Wed, 29 Nov 2023 08:25:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2C84B6B03DE for ; Wed, 29 Nov 2023 08:25:38 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0006C140485 for ; Wed, 29 Nov 2023 13:25:37 +0000 (UTC) X-FDA: 81511063956.30.E68F34F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id C7A384001A for ; Wed, 29 Nov 2023 13:25:34 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701264335; 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; bh=vgDzde4pY4k1GqnqACoj4vz/jHMaBo876Ngk3IPD1kM=; b=ABQ5kWTqilfHf0ecFmgpl4lCaAQYPFKjQ0utt+28++CnxCRGc6hz4H1TqW18Ts8hBjn4B5 W7BcEpj5/pc8k1HhSfABlGTdbjHfS5QHwYzzgXM+sTNP8vsuaPwptKGwfTBFCTObbD6vDV W/GG0WTKoVRB8PrWL5sG3jM2SsEMgv8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701264335; a=rsa-sha256; cv=none; b=iy+3xCtZib1OlLkM5wWG59mxVorXiVK9acezShIG9cUg3SAjjFGHUyb5QA6oM65FV8OBqO jSGDNnUiBtPTOeGmo7T1RkktJ2C5ce/SaACLEIGfbgK8PuIkPUGOv9wP5805HThKV+ToOS u11T8lf1l5PdmxgyUER+kavKZBSSlGg= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A3BCF210DF; Wed, 29 Nov 2023 13:25:32 +0000 (UTC) Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 861A113637; Wed, 29 Nov 2023 13:25:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 47hXIMw7Z2XlRAAAD6G6ig (envelope-from ); Wed, 29 Nov 2023 13:25:32 +0000 Message-ID: Date: Wed, 29 Nov 2023 14:25:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC v2 2/7] mm, slub: add opt-in slub_percpu_array Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: "Liam R. Howlett" , Matthew Wilcox , Suren Baghdasaryan , Christoph Lameter , David Rientjes , Pekka Enberg , Joonsoo Kim , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev References: <20230810163627.6206-9-vbabka@suse.cz> <20230810163627.6206-11-vbabka@suse.cz> <077e8e97-e88f-0b8e-2788-4031458be090@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: +++++++++++ X-Rspamd-Queue-Id: C7A384001A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ht1bwqqpinrb7up6moikscjxkno1uyhq X-HE-Tag: 1701264334-950794 X-HE-Meta: U2FsdGVkX19KkUwVBLaSNLqlZacoABVR0nssV89OTR1Ap8z/jSDVzlptHA58uUjsVyq5dAOJJQ2Am/j2a2YmMJWGypNdTN1LWOz059KOlTNxq/2HphG3NDUvyX2zCgbTgGuhyWnOjKYIZESatFRkRFAFdKavm3NS/7ftc52OcXXnS1wHQCKHaf6okB5WzddYeEaH3ZiyH0tQrUY/ZhqzNepa8P1b8f6kVGAEAC7D8m3uMpt1gahjk5QJAnG9JWrigIoT96VC9gVXYzlvXkcUPuNjvoJJGIZGBLt/hC+87gk8MGZFJ56wTkgyD4X0JoAiBWqN1zvZBAp8NG95L3ov7Hv5/HogRylxGUB2EGXk50T2ki6Lh1PKqnvh83KMOa1ImgZ2diFBydAOYgHQMH9kxlOBB3J+VZEeqz5nA0WsJMRAWhAVCaOZ5++8y+DhijzCx9Oxnkgj/4PC7ZRYtKrTN6OTmLpr7rY2RkYQzsuws0qSUGr6GPgiooKNFdJ2Ewrl6zGxIKfDwkTbhA1oHjY3bb4AXiiZDqFxsJc60lFIX5CR/DbZdiA8XUUDWRjj7AaGNAMslz3aB+cimTjFUIEgpUlCn4f/9bX+JjNbNoOQEuq2UPB8sJcf1HyNgxbh5YLvHN3WMI0AKFQSctanVienJt80kN/qGDscf5nnljNyJZ2Et8MgHYttxHk3u2pPOTjLbRQeShDpdsKmBvAFClCOPAvGCSo2hJfnxBF7vevIeG31yIyu0K5RXyb7bsn9hlQAHWsEaxMlkQIvr9N8quvi2J/jKGigYG/A8S7c4YdOMI7XjQMOh+fbZR+X1o2lqAtAnv+tHBeoKy8fn//FPLY1eP1yEq3Y2hBW8sxruiYf3XE5Ln9WBPA+FjhXI+Xmaw55Ri9wZDV5t7Mq1J7dTX2yDSptQgYIQdIwLdthzcwL7HzkO5bMZrP44rhHlzDgZmZVbx+87pqmIFvTamReBX7 tyNVdqjZ KuMfZWirHGzfzropnTNfxTZQB7Z6IVyDW3Dke4Tq8z+e/cuLleoGio0zqu92+HAjXBETMBSwyJUeid03DH6MyaMLN2e7YT7Jf2qtP5uPFgcb6mkfSZTDjd059G1YUT9Rj/RkUVKMn7nTAdibvdIGlt/6j0Ks7EzSO4MvcHHB15kOwHLmLapZlwK+mybySgeneTU/dFxjYQUpt/FBWGd0cpFz79evevOTAf5MqJa+hS7kF03o= 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: List-Subscribe: List-Unsubscribe: On 11/29/23 01:46, Hyeonggon Yoo wrote: > On Wed, Nov 29, 2023 at 2:37 AM Vlastimil Babka wrote: > >> >> @@ -4060,6 +4201,45 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size, >> >> } >> >> EXPORT_SYMBOL(kmem_cache_alloc_bulk); >> >> >> >> +int kmem_cache_prefill_percpu_array(struct kmem_cache *s, unsigned int count, >> >> + gfp_t gfp) >> >> +{ >> >> + struct slub_percpu_array *pca; >> >> + void *objects[32]; >> >> + unsigned int used; >> >> + unsigned int allocated; >> >> + >> >> + if (!s->cpu_array) >> >> + return -EINVAL; >> >> + >> >> + /* racy but we don't care */ >> >> + pca = raw_cpu_ptr(s->cpu_array); >> >> + >> >> + used = READ_ONCE(pca->used); >> > >> > Hmm for the prefill to be meaningful, >> > remote allocation should be possible, right? >> >> Remote in what sense? > > TL;DR) What I wanted to ask was: > "How pre-filling a number of objects works when the pre-filled objects > are not shared between CPUs" > > IIUC the prefill is opportunistically filling the array so (hopefully) > expecting there are > some objects filled in it. Yes. > Let's say CPU X calls kmem_cache_prefill_percpu_array(32) and all 32 > objects are filled into CPU X's array. > But if CPU Y can't allocate from CPU X's array (which I referred to as > "remote allocation"), the semantics differ from > the maple tree's perspective because preallocated objects were shared > between CPUs before, but now it's not? The assumption is that the operation will prefill on CPU X and then consume it also on X, because shortly after prefill it will enter some restricted context (i.e. spin_lock_irqsave or whatnot) that prevents it from migrating. That's not guaranteed of course, but migration in a bad moment and subsequent depleted array should be rare enough that we'll just handle it in the slow paths, and if it results in dipping into reserves, it won't be too disruptive. > Thanks! > > -- > Hyeonggon