From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 08:50:15 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AEE316A46B for ; Sun, 2 Dec 2007 08:50:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9BFCF13C458 for ; Sun, 2 Dec 2007 08:50:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so1111772mue for ; Sun, 02 Dec 2007 00:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=zZLaDc+UWVVrS+gUNL+zttZNOLgw6jRNMs8P75m2EGk=; b=ohv3qJhznfdCjSwuyAWIahM7bYyVp92Byxeu++MI9sJ8JlDITHEqCaIZiTc4RoTBH1VmMq7BSC3d6uM20ujXCqbpuUhpeSBLCIEUQH5gJhAmsztUylQdL4K2/UniM3zdEQg1F7Xw7TNQD/S6PqJbt57rLqSDA5HZRBJvrxookL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bnciqqyMP4Y3fiL1wg6vlSsaJrmCyMz+/uGtFeQGFRroWAuk3NrZb+jKV2GEhK741GduTk5vmXafVhFRcGY/7mGKhbQG+HsLxYvX5o2iyWO2vURGuZHlBvwE7uilr5CSABWrBFLkzNqdCHc0ubKNCag24M6J0DNO60dG48/JqrQ= Received: by 10.86.51.2 with SMTP id y2mr4396971fgy.1196585412123; Sun, 02 Dec 2007 00:50:12 -0800 (PST) Received: by 10.86.25.3 with HTTP; Sun, 2 Dec 2007 00:50:12 -0800 (PST) Message-ID: <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd@mail.gmail.com> Date: Sun, 2 Dec 2007 09:50:12 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <17366.1196583284@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3bbf2fe10712012231p2945111cma2faed2299167d3a@mail.gmail.com> <17366.1196583284@critter.freebsd.dk> X-Google-Sender-Auth: 597a5b4fca5cb8b9 Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout 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: Sun, 02 Dec 2007 08:50:15 -0000 2007/12/2, Poul-Henning Kamp : > In message <3bbf2fe10712012231p2945111cma2faed2299167d3a@mail.gmail.com>, "Atti > lio Rao" writes: > >2007/12/1, Poul-Henning Kamp : > >> > >> Here is my proposed new timeout API for 8.x. > >> > >> The primary objective is to make it possible to have multiple timeout > >> "providers" of possibly different kind, so that we can have per-cpu > >> or per-net-stack timeout handing. > > > >I have a question so. > > I have no idea what the answer to your question is, I'm focusing on > providing the ability, how we subsequently decide to use it is up > to others. Well, this is part of that too. For things like "per-cpu" timeouts, I expect to have groups bound to the specific CPU you referr to. This kind of group is the only one where I can find a benefit about having a group. I'm not sure what would one expect by having, for example, a tcp-stack group as the generic implementation cannot do optimization on scheduling SWIs. What I'm trying to say is that the 'group' concept is good as an abstraction, but I still can't see what it can bring to us. What really matters about timeouts in SMP systems is how you expolit CPU affinity and how you balance timeouts between them. Doing this on a per-group basis is neither efficient or helpful really as these details should be decided on the consumers side of the matter. Attilio -- Peace can only be achieved by understanding - A. Einstein