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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24341C7EE23 for ; Thu, 1 Jun 2023 17:53:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231423AbjFARxQ (ORCPT ); Thu, 1 Jun 2023 13:53:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231410AbjFARxN (ORCPT ); Thu, 1 Jun 2023 13:53:13 -0400 Received: from out-15.mta1.migadu.com (out-15.mta1.migadu.com [95.215.58.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7570313D for ; Thu, 1 Jun 2023 10:53:12 -0700 (PDT) Date: Thu, 1 Jun 2023 13:53:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1685641990; h=from:from: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=7gLsPpU09ZX1oPA5PFz5u/WQswLV/fVWR9RT9czI1/8=; b=otDvWmsVMNh/LcZg1i8pBTm80teDhhYpay+emHGlZNdXYjInOAyG/6aqM/EmTgw+/2nn/J qqn0XbzbQqp9jxBteAPeeODAmRERpmBSukfT2OjeINaCtgN+4bDT8XKl4xhFvIHexRpXSY tXiy23crK9BdqQtA4wJfHbbwRkhhmcM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Song Liu Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, mcgrof@kernel.org, peterz@infradead.org, tglx@linutronix.de, x86@kernel.org, rppt@kernel.org Subject: Re: [PATCH 0/3] Type aware module allocator Message-ID: References: <20230526051529.3387103-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 30, 2023 at 03:48:51PM -0700, Song Liu wrote: > On Mon, May 29, 2023 at 11:25 AM Kent Overstreet > wrote: > > > > On Sat, May 27, 2023 at 10:58:37PM -0700, Song Liu wrote: > > > I don't think we are exposing architecture specific options to users. > > > Some layer need to handle arch specifics. If the new allocator is > > > built on top of module_alloc, module_alloc is handling that. If the new > > > allocator is to replace module_alloc, it needs to handle arch specifics. > > > > Ok, I went back and read more thoroughly, I got this part wrong. The > > actual interface is the mod_mem_type enum, not mod_alloc_params or > > vmalloc_params. > > > > So this was my main complaint, but this actually looks ok now. > > > > It would be better to have those structs in a .c file, not the header > > file - it looks like those are the public interface the way you have it. > > Thanks for this suggestion. It makes a lot of sense. But I am not quite > sure how we can avoid putting it in the header yet. I will take a closer > look. OTOH, if we plan to use Mike's new allocator to replace vmalloc, > we probably don't need this part. The architectures previously exported constants that were used by module_alloc(), why not stick with that? > AFAICT, we don't have a global text_poke() API yet. I can take a look > into it (if it makes sense). Great > Yeah, that's part of the goal to extend the scope from executable to all > types. Yeah it took me a bit to wrap my head around how this all makes sense - it started out as just a better module_alloc(), then there was lots of talk about hugepages. I like it more now, looking forward to see how it fits together with Mike's work :)