From owner-freebsd-arch@FreeBSD.ORG Sat Nov 10 09:34:48 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A07816A41A for ; Sat, 10 Nov 2007 09:34:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C07A813C491 for ; Sat, 10 Nov 2007 09:34:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id EB58B17105; Sat, 10 Nov 2007 09:34:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lAA9Yb2v063474; Sat, 10 Nov 2007 09:34:37 GMT (envelope-from phk@critter.freebsd.dk) To: "Attilio Rao" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 08 Nov 2007 20:35:07 +0100." <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com> Date: Sat, 10 Nov 2007 09:34:37 +0000 Message-ID: <63473.1194687277@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] callout overhaul: part I X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2007 09:34:48 -0000 In message <3bbf2fe10711081135y3473817ejbc72574e3e8c763d@mail.gmail.com>, "Atti lio Rao" writes: First I'd like to thank you for doing something about this Attilio, I havn't had time for it recently. You are right in many of the points you make, RETURNUNLOCKED, different kinds of locks etc, and we should integrate that into my API proposal. You are also wrong in some places, and I'd like to discuss those. 1. About the name ------------------ In my proposal I used a generic XXX_ prefix, because nailing the name was not the bikeshed I wanted to paint. You have chosen "callout" but I'm not sure I like that very much, this is not really a callout facility, it is a timer facility. I don't like when core APIs have silly long names, that clutters up source code needlessly, so my preference would probably be to use a short prefix, something like "tmr", "when", "wake" or similar. But let's take that offline and not start a bikeshed here. 2. About XXX_instances ----------------------- You propose a XXX_arm() and a XXX_arm_cpu(). That is a pointless limitation. My API proposal said specifically: > The functions above will actually be wrappers for a more generic > set of the same family, which also takes a pointer to a callout-group. And I guess the meaning of this was too subtle, so I will elaborate: The fundamental function will be called XXX_arm_cg(struct xxx_group *cg, ...) The xxx_group argument can be NULL, in which case a group is chosen for you by unspecified means. XXX_arm(...) Is a macro wrapper that calls the above with a NULL argument, and we can make XXX_arm_cpu(...) call it with an argument of pcpu->callout_group if we like. But we do not want to limit ourselves to only those two options, for intance we may find it a benefit later to put long running non-likely callouts in their own group, optimized for such behaviour. (And we cannot settle the group earlier than xxx_arm() if we want to have the per-cpu option, so xxx_init() can't do it) 3. Two stage conversion ----------------------- You propose a two-stage conversion. That is a bad idea when we can do it as efficiently with a one-stage conversion. Having thought a bit more about the conversion, I think the right way to do this is parallel implementations: Lets add the new API and start converting critical code to use it. We may have to retain the old callout-wheel for a couple of releases for compat reasons anyway, and I'm not convinced that it is sensible to emulate the old API with the new, the cost in calculations and memory management may be too high. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.