Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp1325240lqp; Fri, 22 Mar 2024 11:24:05 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW+qo+UFHY9mV97nXkzQdsyKDVw4IvdGKv1ROufai9ttwVa3UOyp8YPBAVmfI+820mNJR1XH4GPO6Cf6g6QO0xp6o8R77+hOUzkzcLfEQ== X-Google-Smtp-Source: AGHT+IGOzhU+NptOQG6dYRPIf0hehwxJnkSS8BlAFjXeGNUcXCzxGT8OUVNWvFBQS1hzHA4l9VEV X-Received: by 2002:a05:620a:36f3:b0:789:e91a:f1ed with SMTP id cz51-20020a05620a36f300b00789e91af1edmr559422qkb.38.1711131845501; Fri, 22 Mar 2024 11:24:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711131845; cv=pass; d=google.com; s=arc-20160816; b=gHdhMLs/YK7YQj7n7WC33isXikxg1mhHFb8bPMdzkANdQXrBay0A6QHNxOr4uuz8Pu m3lQR+WzMk8k9lIIYiWGD0WZOQScZDXbojM7ADTXS7H3w6ypGzNf1eoJ7OqpWMeW9/Sx Z5L2wAF/Dvwh3T2apY+ahZydp+0IeIMjwAf+lYDFdxjw7YOgJVwXVkEoW2VZ7xx9dSYZ qP3JleFofUvQ4yRzRNrWPu2QbFe/ZBH6JX0YxSFxqqXFceMlWOVXQE1ytXMnzfSx+8fl LyK5DQaiKewt4QiaZ+N5QYwb8vsVHKEE0Gt7JhfshCNRQJwWSI9TURjc84IxnS3u0Hjw DwFg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:dkim-signature:date; bh=HGAD06oDDixz/25yvLztOQXn8pWPlf8SP7amw2+5Ywg=; fh=xNHfdL6dXcw4Xj2CobF4BJICK/hBQkS4/fw+UOO3WQM=; b=aS90yP6d50TOJ17lb/U/O376RAYKti0p3qiGWbDIiNa6tH2tK14pLIjq4+4oKfEi22 oWHp9jr3CWsvtnXYEfsRVk4BC2IwEAuXlmBjaAWLbsKS/xgJasTkArEiJpvApnz8QPdj Bl764f9982Gzk/WdeB8POCU/pK+xw/J5CNozPRGvc24213lItABIjLQ0hRRorm9Ct+Dd fPGKiDTIIW+8zw4qW1NzqLeloxDhhm9VSbQTz8dKqTe8TL+L77LjVy54aTWN49pCXOGs 8ZZHME18eIW5mStjRkfM9bQX8uUyV5YiFroAwE2Ew4PB/4aqrho/AvpDiMkzQRc1+ybB bUCQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=rn45MCTu; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-111937-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-111937-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id os42-20020a05620a812a00b0078a280a7a9esi122039qkn.118.2024.03.22.11.24.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 11:24:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-111937-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=rn45MCTu; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-111937-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-111937-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 3737D1C23359 for ; Fri, 22 Mar 2024 18:24:05 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B1ED465BA1; Fri, 22 Mar 2024 18:23:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="rn45MCTu" Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D2F565BB2 for ; Fri, 22 Mar 2024 18:23:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711131814; cv=none; b=Gopq4WmWvow8TH3dU+1I/1YoE7l3rmrloUjhEy2l05XWDT50ivi/iYl/dSb+S3Yf4ZjvLMwXxAxyGL/AHZJ6JtU9et7sbxevOAtRkS563Z5R1FlyGr6Sr7MVb5+77YOR4J2tsM4G59PWBILT2RRshGfXXXqNNV4MFuKAw0Rz4II= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711131814; c=relaxed/simple; bh=40VVfM6/809+pYJgj2wzfEjVNEU0Bg0sahyBYokr3rE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GkcaZAXHJywHx8R+FZlYT4ll0xK2G4QThGoxPhgDHKQhrQUrTdPC8Fzbr/qPg0CcAkVKVSWQJvMjT8Krtb6skBz6vczgkDxbm3iXkrCDikdwSPUeklsoESvAw0Vw3yYF/MfS7J5fgik0Mcwu8ZO7QpqO7QAGDUIpQGNPYMlpbtk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=rn45MCTu; arc=none smtp.client-ip=95.215.58.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Date: Fri, 22 Mar 2024 14:23:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711131811; 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: in-reply-to:in-reply-to:references:references; bh=HGAD06oDDixz/25yvLztOQXn8pWPlf8SP7amw2+5Ywg=; b=rn45MCTud1uEVpZzz9hgmmrzdwnqyZPa0nupO4gg+Qbf2//Ozo+YE4rOBPIR+OrlOyb4J9 KKQxqH4RWXeS5pOhyk+/FblibwpYDe/DPpMOxRIax59Wu2wtT2bu7C9YHjW2fWxCE7M2wA x/Wd5P9nsmTnXr8zB9yZHQDt+9+I0A8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kuan-Wei Chiu Cc: colyli@suse.de, msakai@redhat.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, namhyung@kernel.org, akpm@linux-foundation.org, bfoster@redhat.com, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, jserv@ccns.ncku.edu.tw, dm-devel@lists.linux.dev, linux-bcache@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH v2 04/15] lib min_heap: Add type safe interface Message-ID: References: <20240320145417.336208-1-visitorckw@gmail.com> <20240320145417.336208-5-visitorckw@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On Sat, Mar 23, 2024 at 01:02:29AM +0800, Kuan-Wei Chiu wrote: > On Thu, Mar 21, 2024 at 05:22:14PM -0400, Kent Overstreet wrote: > > On Thu, Mar 21, 2024 at 07:57:47PM +0800, Kuan-Wei Chiu wrote: > > > On Wed, Mar 20, 2024 at 04:56:57PM -0400, Kent Overstreet wrote: > > > > On Wed, Mar 20, 2024 at 10:54:06PM +0800, Kuan-Wei Chiu wrote: > > > > > Introduce a type-safe interface for min_heap by adding small macro > > > > > wrappers around functions and using a 0-size array to store type > > > > > information. This enables the use of __minheap_cast and > > > > > __minheap_obj_size macros for type casting and obtaining element size. > > > > > The implementation draws inspiration from generic-radix-tree.h, > > > > > eliminating the need to pass element size in min_heap_callbacks. > > > > > > > > let's avoid the heap->heap.nr - darray (fs/bcachefs/darray.h) has a > > > > trick for that. All heaps have the same memory layout, so we can just > > > > cast to a void pointer heap to get something the C code can use. > > > > > > > If I understand correctly, you're suggesting adding APIs similar to > > > darray_top(), darray_first(), and darray_last() within min_heap and > > > having them return a pointer. However, some users are using heap.nr in > > > conditional statements instead of utilizing heap.nr for memory > > > operations, so returning pointers may not be as convenient. What about > > > adding get and set functions for nr instead? > > > > No, I mean not having separate inner and outer types. Want me to sketch > > something out? > > Based on your suggestion, I've come up with the following code snippet: > > #define MIN_HEAP_PREALLOCATED(_type, _name, _nr) \ > struct _name { \ > int nr; \ > int size; \ > _type *data; \ > _type preallocated[_nr]; \ > }; > > #define MIN_HEAP(_type, _name) MIN_HEAP_PREALLOCATED(_type, _name, 0) > > typdef MIN_HEAP(char, _) min_heap_char; > > static __always_inline > void min_heap_init(min_heap_char *heap, void *data, int size) > { > heap->nr = 0; > heap->size = size; > heap->data = size <= ARRAY_SIZE(heap->preallocated) ? heap->preallocated : data; > } > > But I'm not sure how to implement other inline functions like > min_heap_push or min_heap_pop if I do that, unless they are rewritten > using macros. Also, I'm not sure how to make the less and swp functions > in the min_heap_callbacks not use void * type parameters. Or perhaps I > misunderstood your meaning again. If you could sketch out your idea or > have a better approach, it would be a great help to me. Any guidance > would be greatly appreciated. No, you're on the right track. To call C functions on different types of heaps you have to cast them all to a common type, say HEAP(char), also pass the element size as a paremeter (which you had to do previously anyways).